Full-Time
Commercial Finance Lead
Tiger Data
11-50 employees
Open-source time-series database platform
No salary listed
Remote in USA
Remote
Remote within North American time zones, ideally the East Coast.
 Finance & Banking (1) |
|---|
Get referred to Tiger Data
See people who can refer or advise you
- Have 6+ years of experience across Commercial Finance, business operations, strategy, sales, marketing, or data roles in a SaaS or technology company.
- Understand consumption-based models and how pipeline, conversion, usage, retention, and expansion drive revenue.
- Have built detailed operational forecasts and can translate commercial activity into a forward-looking growth outlook.
- Be highly analytical, with strong financial modeling, Excel, business intelligence, and data skills.
- Understand SaaS and cloud economics, including retention, expansion, and sales productivity.
- Connect fragmented data across commercial, product, and financial systems into a coherent view of the customer and business.
- Look beyond lagging results to identify the leading indicators most predictive of future performance.
- Challenge assumptions, align senior leaders, and influence without direct authority.
- Be comfortable moving between detailed analysis and C-suite discussions.
- Own the forward-looking commercial model and bottoms-up forecast, including its data, methodology, and assumptions across pipeline, conversion, customer usage, retention, expansion, sales capacity, and timing.
- Provide FP&A with the commercial outlook and operating assumptions used to forecast revenue, spending, margin, and cash.
- Build complex cohort and financial dashboards covering acquisition channels, customer profiles, conversion, usage, churn, and expansion.
- Identify leading indicators, pressure-test growth targets, and flag risks before they appear in financial results.
- Analyze performance against plan and translate underlying drivers into risks, opportunities, and recommended actions.
- Evaluate investments across sales capacity, marketing programs, customer expansion, partnerships, and new routes to market.
- Partner with Revenue Operations, Sales, Marketing, Customer Success, and FP&A to align assumptions, set targets, identify investment needs, and drive action.
- Prepare clear, executive-ready materials for leadership and Board discussions, communicating conclusions, assumptions, and recommendations in an easily digestible manner.
- Apply emerging artificial intelligence technologies to accelerate analysis, improve forecasting, and expand capacity for high-leverage work.
Timescale builds and maintains TimescaleDB, a time series database built on PostgreSQL. It handles large volumes of time-stamped data efficiently and provides a SQL interface for querying, with features like hypertables for scalable partitioning. The product is available as an open-source core, with premium features, enterprise support, and a fully managed multi-cloud cloud service for on-premise, edge, or cloud deployments. Timescale differentiates itself by leveraging PostgreSQL compatibility, offering flexible deployment options, and combining an open-source base with paid enhancements and managed services. The company's goal is to help organizations store, analyze, and act on time series data at scale, serving industries like IoT and financial services with reliable real-time analytics.
Company Size
11-50
Company Stage
Series C
Total Funding
$184.8M
Headquarters
New York City, New York
Founded
2015
Get referred to Tiger Data
See people who can refer or advise you
Simplify's Take
What believers are saying
- July 2026 compression upgrades deliver 160x faster writes and 70x faster summary queries.
- July 2026 PrivateLink, disaster recovery, and new regions reduce enterprise procurement friction.
- June 2026 Ghost's free tier and 3,000-customer base create a strong developer funnel.
What critics are saying
- June 2026 Ghost and TimescaleDB Enterprise split engineering focus, slowing core database execution.
- ParadeDB, ClickHouse, and managed PostgreSQL vendors attack Tiger Data's analytics and AI use cases.
- If Postgres-native consolidation stalls, customers keep separate analytics stacks and Tiger Data becomes optional middleware.
What makes Tiger Data unique
- Tiger Data pairs TimescaleDB with PostgreSQL, keeping operational analytics inside one SQL stack.
- June 2026 Ghost targets AI agents with forkable databases, CLI access, and per-query pricing.
- July 2026 Enterprise extends Postgres to on-prem, edge, and customer-managed clouds with Cloud Sync.
Help us improve and share your feedback! Did you find this helpful?
Benefits
Remote Work Options
Stock Options
Phone/Internet Stipend
Professional Development Budget
Health Insurance
Growth & Insights and Company News
6 month growth
↓ -4%1 year growth
↓ -2%2 year growth
↓ -2%What's new in Tiger Cloud: bigger performance gains, wider platform reach, better visibility. July 17th, 2026 This year, Tigerdata has focused on improving three areas that define the Tiger Cloud experience: * Scale without splitting your architecture: Compression becomes a performance advantage. UPDATE and DELETE on compressed data run up to 160x faster, summary queries up to 70x faster. Storage scales to 80,000 IOPS and 64 TB on demand. * Spend less time configuring, more time shipping: Tiger Console auto-tunes hypertables, the PostgreSQL Source Connector moves data to Tiger Cloud without custom pipelines, and pg_textsearch brings production-ready BM25 search natively in Postgres. * Production-grade reliability, without the DIY tax: Tiger Cloud handles data residency, network isolation, disaster recovery, and visibility so you don't have to. This past quarter Tigerdata shipped deeper query engine optimizations in TimescaleDB, new regions, new enterprise networking options, and a long list of smaller improvements to how Tiger Console works day-to-day. Instead of listing every Tiger Cloud release on its own, here's what it adds up to, and why it matters: you can stay on Postgres as you scale, you'll spend less time configuring and more time shipping, and you get the reliability and visibility that time-series workloads actually need. Scale without splitting your architecture. The moment analytical queries start competing with transactional ones, teams feel pressure to bolt on a separate analytical database. This quarter's TimescaleDB releases and storage upgrades ensure Postgres keeps scaling for time-series and analytical workloads instead of becoming the reason you re-architect. Here's what shipped, and why it matters. Run queries and writes directly on compressed data, without the performance tax. Compression used to mean a trade-off: a smaller footprint for slower access. With the release of TimescaleDB v2.26, that trade-off keeps shrinking. Aggregate queries like COUNT, MIN, MAX, and FIRST/LAST now read straight from compressed metadata instead of decompressing full batches, up to 70x faster. Grouping with time_bucket runs roughly 3.5x faster. Multi-column filters push down directly into compressed scans, cutting unnecessary decompression by half or more. Writes get the same treatment. TimescaleDB v2.27 lets UPDATE, DELETE, and UPSERT on compressed chunks skip decompressing data that can't match, so selective write operations run up to 160x faster. Query rewriting can automatically route matching aggregations to a continuous aggregate, and continuous aggregate refreshes can compress chunks as part of the same job instead of needing a separate policy. Continuous aggregates are now more reliable at scale. Tigerdata fixed three stability issues that were constraining them: a memory leak, query correctness edge cases, and a deadlock during concurrent refreshes. As a result, you can now push continuous aggregates harder without operational workarounds or special handling. Add full-text search without adding a search engine. As part of the pg_textsearch v1.0.0 release, BM25 full-text search now runs natively inside Postgres, and is production-ready. Add relevance-ranked search to your application without standing up and syncing a separate Elasticsearch cluster. In benchmarks at 138 million documents, pg_textsearch ran up to 6.5x faster than ParadeDB on typical multi-word queries and sustained 8.7x higher concurrent throughput. It ships with an <@> query syntax, a bm25_force_merge function for segment consolidation, and support for Postgres 17 and 18. One less system in your stack to operate and keep in sync. Scale storage on demand instead of provisioning for a peak that may not come. Scale plan services can now choose between 16,000 and 40,000 IOPS with up to 1,500 MB/s of throughput. Enterprise plans go up to 80,000 IOPS and 2,000 MB/s, with total capacity up to 64 TB. Changes apply without downtime, and you pay only for the IOPS you use. Size up as your workload grows instead of guessing at peak load today. Spend less time configuring, more time shipping. None of the above matters much if half your week still goes to console configuration instead of building. The following updates hand more of that time back to you so you can focus on what matters: building your product, not configuring your database. Build hypertables in a few clicks, without writing SQL. Define hypertable columns directly in Tiger Console instead of writing SQL. Configure a columnstore in the same step. For the best performance, you can enable automated chunk tuning afterward, so you won't have to manually set chunk intervals. Move data from Postgres into Tiger Cloud without building your own pipeline. The PostgreSQL Source Connector is now stable and ready for production use. Replicate an existing Postgres database into Tiger Cloud without hand-rolling a migration or sync pipeline. It supports a configurable worker count for the initial data copy, table selection by publication or direct selection, SSH tunneling, and bulk updates for table and schema mappings. Everything you need to bring production data over reliably. Production-grade reliability, without the DIY tax. Data residency, network isolation, disaster recovery, and visibility into what's happening inside your database are table stakes for any fully-managed platform. The whole point of choosing Tiger Cloud is that you shouldn't have to design, build, and maintain that infrastructure yourself. Here's what shipped this quarter that takes more of that off your plate. Meet data residency requirements in more places. Keep database traffic off the public internet. Private endpoint support is now generally available across every supported AWS and Azure region. AWS PrivateLink connects from your VPC over the AWS private network. Azure Private Link does the same from your VNet over Microsoft's private backbone. Both are configured directly in Tiger Console and included on Scale and Enterprise plans, so database traffic never has to touch the public internet. Recover easily when a region goes down. Catch problems in the tools you already use, before they escalate. Visibility should be simple. You shouldn't have to wait for a problem to surface before you can see it coming. The Tiger Cloud status page now lives at status.tigerdata.com, tied directly into incident response, so you can subscribe and get notified the moment an incident is created, updated, or resolved instead of finding out from a support thread. Inside the Metrics tab in Tiger Console, a new Queries per Second graph gives a real-time view of throughput, making it easier to spot spikes or drops in query volume. In the Insights tab, the query deep dive page now tracks CPU, memory, and storage IO (read and write) over time, so you can catch a query's resource footprint trending the wrong way and see its downstream impact on system health before it turns into a bigger problem. Additionally, you can check the Chunk timeline in the Explorer tab to see how your data is organized across chunks. You can inspect sizes, time ranges, and whether each chunk is in the rowstore or columnstore. This lets you spot organization issues and monitor columnstore job health without running system queries. Try Tiger Cloud for free. All of these features are live on Tiger Cloud. If you're already a customer, sign in and check out the latest TimescaleDB releases on your compressed hypertables and the new IOPS options if you're storage-bound. If you're new to Tiger Cloud, start a free trial and see what a Postgres-native operational analytics database looks like.
What Tigerdata heard: three patterns from Spring 2026 events. July 1st, 2026 Spring 2026 was relentless. Tiger Data teams covered ten events across Europe and the US: GrafanaCON in Barcelona, Hannover Messe and AWS Summit Hamburg in Germany, AWS Summit London, ETHDenver in Colorado, the Offshore Technology Conference in Houston, Data Driven Oil & Gas in Texas, Sensors Converge and IOT Tech Expo in the Bay Area, and AWS Summit Los Angeles. Hundreds of conversations with platform engineers, SREs, industrial automation teams, oil and gas operators, blockchain infrastructure builders, and sensor hardware teams. That's a lot of badge scans. Three patterns kept showing up across every audience, and they're really different angles on the same shift: the market has moved past category education and into implementation-level scrutiny. Here's what that looked like on the ground. Pattern 1: Postgres is becoming the default for industrial and operational telemetry. Five years ago, telemetry workloads at scale defaulted to purpose-built time-series databases. InfluxDB. Prometheus. Specialized vertical stacks. The conversation at the booth has changed. At Hannover Messe, the world's largest industrial trade show, the most common question from automation and manufacturing teams was some variant of: "we have tens of thousands of sensors writing constantly, our current system is buckling, what do you do differently." Not "should we use a time-series database." Not "what is TimescaleDB." Those teams had already chosen Postgres before they walked up. They wanted to know if Tiger Data could keep them on it at the volumes they were already running. At Sensors Converge, the audience skews closer to the hardware end of the IIoT pipeline: sensor manufacturers, embedded systems engineers, and the people writing firmware for the devices feeding everyone else's databases. The questions were specific. How does storage behave when you're sampling at 100 Hz across 50,000 endpoints. What happens when a fleet of devices comes back online after a network outage and dumps a backlog. Workload questions, not category questions. At the Offshore Technology Conference in Houston, the energy sector followed the same shape. SCADA telemetry. Well monitoring. Equipment digital twins. Lifecycle analytics on multi-decade asset histories. Teams that already had Postgres in production wanted to know how far they could push it before having to reach for another system. The answer, increasingly, is further than they had assumed. The pull toward Postgres in these markets is consistent. Existing Postgres in production. Existing SQL skills on the team. No appetite for a second on-call rotation. Industrial software is conservative for good reasons, and the system that already runs the business is a much better starting point than a green-field rewrite. Customers like Mechademy, Flogistix, and Axpo are public references for what this looks like in production. Pattern 2: Split-architecture fatigue is becoming an explicit conversation. The second pattern builds directly on the first. Teams who split their architecture into "Postgres for transactions, ClickHouse or a warehouse for analytics" are increasingly explicit about regretting it, something Tigerdata has been arguing internally for years and are now hearing back from the field. At AWS Summit London, the booth was dense with platform engineers running on RDS or Aurora and feeling the analytical wall closing in. The question was usually some version of: "we are about to add a separate analytics database. Is there a path that does not require us to do that." A few years ago, the answer most teams accepted was no. They added the second system, built the pipeline, accepted the lag, and moved on. The conversation now starts from a different premise. Teams have either watched a peer team go through the split and pay the operational tax, or they have done it themselves and want out. At Hannover and OTC, the same pattern appeared on a longer timeline. Industrial teams that built their architectures a decade ago, with operational data in one place and analytics in another, are increasingly looking at consolidation. Multi-system data plumbing is one of the largest hidden line items in their engineering budget. The pitch that operational analytics can stay on the source of truth, with no pipeline, no drift, no second backup strategy, is landing differently than it did even two years ago. Speedcast's story is the cleanest public version of the before-and-after. They stitched together Kafka, Flink, and custom code to stream data from Postgres to Iceberg, and Tiger Lake replaced all of it. As Kevin Otten, their Director of Technical Architecture, put it: "It's the architecture we wish we had from day one." Pattern 3: The questions have gotten harder, and that's the clearest evidence of the first two. Across all ten events, the conversations got deeper than at any event series Tigerdata has run. The questions skipped the basics, and that alone says something: teams don't ask about compression ratios and failure modes when they're still deciding on a category. They ask once they've already made the decisions in Patterns 1 and 2, and they're just checking the implementation. At GrafanaCON, booth visitors asked about continuous aggregates, compression ratios, and how Hypercore behaves under high-cardinality dashboards. These are the questions teams ask when they are comparing implementations. The Grafana community is one of the most technically opinionated audiences Tigerdata talk to, and the depth of the questions has been climbing event over event. At Sensors Converge, the questions ran the same way at the hardware level. Specific sample rates. Specific endpoint counts. Specific failure modes. Nobody wanted a feature tour. They wanted to know whether the system would behave the way they expected under their workload. The share of conversations that started with "what is a time-series database" or "what is TimescaleDB" was lower than at any event series Tigerdata has run. The market has moved past category education. People know what they need, and they are picking implementations. That's the throughline across all three patterns: teams have already decided Postgres can carry this weight, they're done paying the split-architecture tax, and now they're evaluating implementations instead of categories. That's a good problem for a database company to have. Where you'll find Tigerdata next. The calendar doesn't really do summer breaks. If you want to keep the conversation going, here's where Tigerdata'll be through the end of the year: More events coming Want to connect at an event not on this list? Reach out. If Tigerdata is not coming to your city, the Tiger Cloud trial is open whenever you are.
One database swap cut equipment monitoring costs 60%. June 20, 2026 Manufacturing and energy companies collecting sensor data at scale are hitting the same wall: PostgreSQL, SQL Server, Oracle, and MongoDB were not designed for the volume, velocity, and retention demands of industrial time series. Mike Freedman, Co-founder and CTO at Tiger Data, spoke with Lucian Fogoros of IIoT World at Hannover Messe 2026 about what breaks first when standard databases face industrial data loads, how a purpose-built time series architecture delivers 10x faster queries, and what changes when the database has to run 100 meters underground in a mine or on a ship crossing the Atlantic. Why standard databases break under industrial data loads. Industrial facilities collecting sensor data at scale generate volumes that overwhelm general-purpose databases, especially when companies want to retain three, seven, or ten years of historical records. The databases running underneath historians and data systems were not built for that scale. They run too slowly, consume too much storage, and lack the internal optimizations needed to make long-term retention cost-effective. TimescaleDB, Tiger Data's open source time series database built on PostgreSQL, addresses this with columnar representation and purpose-built compression that reduces both query time and storage footprint. At the company's Hannover Messe booth in Hall 14, live demos showed TimescaleDB running against the same datasets at 10x the speed of standard Postgres, SQL Server, Oracle, or MongoDB. Dashboards that previously crawled through results returned answers that felt instant. Faster queries and smaller storage footprints change what companies can do with their data. When both improve by an order of magnitude, companies stop discarding older records to manage costs. Years of historical records become available for real-time analytics and AI applications, opening use cases that were previously impractical with conventional database architectures. When sensor data cannot leave the building. Data sovereignty requirements, particularly in Europe, increasingly mandate that operational data stay within specific facilities or jurisdictions. On top of regulatory pressure, many industrial sites have weak or no internet connectivity. Tiger Data has customers running their database 100 meters underground in mines, on ships crossing the Atlantic, and on deep water oil rigs off the coast. In each case, the database must sit alongside the equipment it monitors. This is the gap that TimescaleDB Enterprise, first shown at Hannover Messe 2026, was designed to fill. The product wraps Tiger Data's market-proven database core with enterprise-grade operations: high availability replication, managed upgrades, monitoring and alerting, administrative controls, and AI enablement. It puts managed-service convenience on the customer's own servers. A feature called cloud sync provides an optional bridge for operators who want enterprise-wide visibility. Local data syncs from any site up to a centralized cloud, while the primary database stays at the industrial edge. The architecture spans three tiers: the edge device or equipment, the on-site facility, and an optional centralized cloud for cross-facility analytics and reporting. Previously, Tiger Data's primary engagement model was a fully managed cloud service running on AWS and Azure, used by thousands of companies in industrial and energy sectors. Enterprise extends that reach to sites where cloud is not an option. What open source and OPC UA mean for plant-level data integration. Before any formal partnership existed, users of Inductive Automation's Ignition platform had been pairing it with TimescaleDB on their own for seven years. The pattern was consistent enough to act on: Ignition, built around open protocols like OPC UA, handled data collection and visualization, while TimescaleDB, built on the open PostgreSQL ecosystem, handled storage and querying at scale. Plant engineers and developers were assembling the stack themselves. Tiger Data and Inductive Automation decided to formalize that into a supported, natively integrated product. Instead of a DIY assembly where each team figures out the integration independently, the two platforms now work together by design, built for mission-critical enterprise workloads. TimescaleDB launched in 2017 and has been in the market for over seven years as an open source product, meaning the community adoption happened before any commercial push. The result for a plant engineer or developer: a supported industrial data stack that pairs an OPC UA-native data platform with a Postgres-compatible time series database, without having to build the glue layer in-house. 60% cost reduction monitoring remote compression equipment. One Tiger Data client monitors about 3,700 pieces of compression equipment across remote oil fields with spotty cellular connectivity. After deploying a time series database architecture, infrastructure costs dropped by 60% and data reliability improved from 95% to 99%. The case illustrates both deployment patterns that purpose-built time series databases support in energy operations. Software developers use the database directly as the underlying data architecture for their industrial applications. It also sits underneath other industrial historians and data systems that need a storage layer capable of handling the new volume and frequency of sensor data. In both cases, columnar representation and time series optimization reduce operational overhead while expanding what can be done with the stored data. | Deployment Challenge | Standard Database | Purpose-Built Time Series Database | | Query speed on industrial data | Slows with volume, dashboards crawl | 10x faster, instant dashboard response | | Storage for 3-10 years of data | Cost-prohibitive at scale | Columnar compression, smaller footprint | | Edge / on-prem deployment | Limited options, self-managed | Managed operations on customer servers | | Data sovereignty compliance | Requires custom architecture | On-prem with optional cloud sync | | OPC UA integration | Manual pairing | Native Ignition partnership | | AI and analytics readiness | Separate infrastructure required | Built-in AI enablement | Frequently asked questions. 1. Why do industrial sensor databases need to be different from standard databases? Industrial sensor data is time series data, collected at high frequency across thousands of assets and retained for years. Standard databases like PostgreSQL, SQL Server, or MongoDB were designed for transactional workloads, not for the sustained write throughput and long-range historical queries that manufacturing and energy facilities demand. Purpose-built time series databases use columnar storage and compression optimized for this access pattern. 2. Can time series databases run at the industrial edge without cloud access? Yes. Products like TimescaleDB Enterprise are designed to run on-premises, at remote sites, and in environments with limited or no internet connectivity, including mines, ships, and offshore oil rigs. An optional cloud sync feature allows data to be replicated to a centralized cloud for enterprise visibility without requiring constant connectivity. 3. How does the Ignition and TimescaleDB partnership work? Tiger Data and Inductive Automation formalized a partnership after seven years of community-driven adoption. Ignition handles data collection via OPC UA, while TimescaleDB provides Postgres-compatible time series storage. The integration is now natively supported rather than requiring each team to build and maintain the connection independently. 4. What cost savings can manufacturers expect from purpose-built time series databases? Results vary by deployment, but one documented case in remote oil field monitoring showed a 60% reduction in infrastructure costs and an improvement in data reliability from 95% to 99% across 3,700 pieces of compression equipment. Savings come from smaller storage footprint, faster queries, and reduced operational overhead. This article is based on a video interview with Mike Freedman, Co-founder and CTO at Tiger Data, and Lucian Fogoros of IIoT World, recorded at Hannover Messe 2026. AI tools were used to help summarize and organize the content. Reviewed and edited by the IIoT World editorial team.
Tiger Data launches Ghost, a purpose-built database service for the agentic era. Published: June 9th, 2026 NEW YORK - Tiger Data, the team behind TimescaleDB and over a decade of Postgres engineering, today announced the general availability of Ghost, a database service designed and built specifically for AI agents. Ghost addresses a gap that has become one of the most pressing infrastructure problems in AI: developers need databases built for collaborating with agents, not retrofitted from tools designed only for humans. "As teams run coding agents, research agents, and workflow agents at scale, they are discovering that the infrastructure underneath them wasn't designed for the way agents actually work," said Ajay Kulkarni, co-founder and CEO of Tiger Data. "Ghost is built specifically for that environment, providing limitless terrain for agents to experiment without putting production at risk." Ghost: the database service built for developers and their agents. Agents experiment constantly and need isolation to do it safely. When an agent fails, the blast radius should be one database, not a shared environment that other agents and humans depend on. Ghost provides unlimited Postgres databases with fast forking, access through the Ghost CLI or MCP server, and databases ranging from ephemeral to dedicated always-on instances. Ghost also makes a new kind of experimentation economically viable. Spinning up dozens of isolated Postgres databases, one per task, per agent, per hypothesis, has historically been cost-prohibitive - or out of the bounds of common free tier limits - enough that teams reused a handful of shared environments instead. Ghost's per-query pricing model makes individual databases cheap enough to treat as disposable, unlocking trial-and-error workflows at a scale that was previously impractical. Key features of Ghost: * Free tier with 100 compute hours/month and 1TB storage, hundreds of DBs and forks * Native compatibility with any MCP-enabled agent harness, including Claude Code, Cursor, Windsurf, Codex, Gemini CLI, and VS Code. * Robust dedicated tier when users are ready to graduate to production, starting at $10/month, built on the most performant Postgres, TimescaleDB. "I don't use Ghost. My Claude Code agent does," said Jacky Liang, Developer Relations Lead of OpenRouter. "If you asked my CC sessions how they feel about Ghost, it's that it's the easiest and most agentive-native database they've ever used. The CLI/MCP-only experience is genius." Ghost is built by the Tiger Data team, the creators of TimescaleDB, the leading open-source time-series database built on Postgres. Ghost is built on the same foundation. Postgres offers one query language, one operational model, and a thriving extension ecosystem - the same infrastructure teams already know how to run. Ghost is available today, with a free tier of 100 compute hours per month and 1TB of storage, and hard spending caps on paid tiers. Documentation, deployment guides, and quickstarts are available at tigerdata.com. Article tags.
Tiger Data launches PostgreSQL extension designed for AI agents. Tiger Data today introduced a managed PostgreSQL database service designed specifically for AI agents, saying conventional database architectures are poorly suited to a future in which software is increasingly built and operated by autonomous agents. The New York-based company, whose business name is Timescale Inc., said the new Ghost service addresses a growing need for infrastructure that supports large-scale experimentation by coding and workflow agents. The service is generally available today. Founded 10 years ago, Tiger Data has evolved from its roots building a PostgreSQL extension for time-series data "into a database platform that's used across 3,000 customers," said co-founder and Chief Executive Ajay Kulkarni. Ghost is built on PostgreSQL but reimagines how databases are provisioned and consumed by AI systems, he said. "The idea is that all new applications are being built with coding agents," Kulkarni said. "We believe the agent is the future packaging of software. Instead of an application, users want outcomes." However, agent-driven development creates new infrastructure requirements because agents frequently experiment, create temporary environments and test alternative approaches. "They don't always do it safely," Kulkarni said. "The database layer can get really expensive and dangerous if you let your agents experiment and go wild." To address that problem, Ghost allows agents to spin up unlimited databases with "fast forking," a feature that lets users create an exact, independent copy of a dataset in minutes or seconds, bypassing long copying times. Tiger Data charges based on active compute usage rather than per-database licensing. "Databases are free," Kulkarni said. "You could have one database per agent or one database per task. You can create it in seconds." Copy-on-write storage. The service is built on Tiger Data's proprietary Fluid Storage technology, a copy-on-write storage layer that allows multiple database instances to share underlying data blocks. Instead of paying for data copies, users only pay for data that changes. Kulkarni compared the architecture to pointers that reference common storage until modifications occur. "If one database starts diverging and writes new blocks to disk, it only has to keep track of the new blocks," he said. Tiger Data is positioning Ghost as an evolution of PostgreSQL to modernize for agents rather than an alternative to it. The company also emphasizes compatibility with the broader PostgreSQL ecosystem. Ghost supports popular extensions including TimescaleDB, pgvector and PostGIS. Early adopters are already Ghost in ways Tiger Data didn't initially anticipate, Kulkarni said. "It's kind of serving as a scratch pad for agents," he said. He described one case in which the platform was used to analyze operational data by having an AI assistant create a temporary database, load a dataset, perform analysis and then discard the environment afterward. Despite the rise of new AI-focused data infrastructure like vector databases, Kulkarni expects PostgreSQL to remain at the center of AI development. "I would be surprised if the database for agents is not Postgres," he said. "Postgres is reliable, it's flexible, it's extensible. It also has a huge ecosystem and community." Tiger Data has 200 employees in 25 countries. The company has raised $180 million in funding. Image: siliconangle/microsoft designer. A message from John Furrier, co-founder of SiliconANGLE: Support its mission to keep content open and free by engaging with theCUBE community. Join theCUBE's Alumni Trust Network, where technology leaders connect, share intelligence and create opportunities. * 15M+ viewers of theCUBE videos, powering conversations across AI, cloud, cybersecurity and more * 11.4k+ theCUBE alumni - Connect with more than 11,400 tech and business leaders shaping the future through a unique trusted-based network. About SiliconANGLE Media SiliconANGLE Media is a recognized leader in digital media innovation, uniting breakthrough technology, strategic insights and real-time audience engagement. As the parent company of SiliconANGLE, theCUBE Network, theCUBE Research, CUBE365, theCUBE AI and theCUBE SuperStudios - with flagship locations in Silicon Valley and the New York Stock Exchange - SiliconANGLE Media operates at the intersection of media, technology and AI. Founded by tech visionaries John Furrier and Dave Vellante, SiliconANGLE Media has built a dynamic ecosystem of industry-leading digital media brands that reach 15+ million elite tech professionals. Its new proprietary theCUBE AI Video Cloud is breaking ground in audience interaction, leveraging theCUBEai.com neural network to help technology companies make data-driven decisions and stay at the forefront of industry conversations.