Agents are the New Developer

80% of Claude Code was written by AI. More than a quarter of all new code at Google was generated by AI one year ago. It’s safe to say that in the next 12 months, the majority of all new code will be written by AI.

Agents don’t behave like humans. They behave in new ways. Software development tools need to evolve. Agents need a new kind of database made for how they work.

But what would a database for agents look like?

At Tiger, we’ve obsessed over databases for the past 10 years. We’ve built high-performance systems for time series data, scaled Postgres across millions of workloads, and served thousands of customers and hundreds of thousands of developers around the world. 

​​So when agents arrived, we felt it immediately. In our bones. This new era of computing would need its own kind of data infrastructure. One that still delivered power without complexity, but built for a new type of user. 

How do agents behave?

• Agents don’t click, they call.
• Agents don’t remember, they retrieve.
• Agents can download expertise to become experts.
• Agents can parallelize effortlessly, acting like a multi-threaded team.
• Agents need a safe sandbox where they can play (or wreak havoc).
• Agents can also hammer your infrastructure (and your budget) if you’re not careful.

We started on this problem over a year ago. Multiple teams working in parallel, months of engineering and internal user feedback, rethinking everything from the storage layer to how agents actually reason. 

Here’s what we built. 

Introducing Agentic Postgres

Today we’re launching Agentic Postgres, the first database designed from the ground up for agents. It includes:

The best database MCP server ever built

Agentic Postgres includes our new MCP server that enables agents not just to interact with the database but also understand how to use it well. We’ve taken our 10+ years of Postgres experience and distilled it into a set of built-in master prompts. This gives agents safe, structured access to the database through high-level tools for schema design, query tuning, migrations, and more. The MCP server also performs native full-text and semantic search over the Postgres docs, so agents can instantly retrieve the right context as they think. 

> I want to create a personal assistant app. Please create a free service on Tiger. Then using Postgres best practices, describe the schema you would create.

Native search and retrieval

Agentic Postgres comes with native full-text and semantic search built directly into the database. For semantic search, we’ve improved our existing extension pgvectorscale, for higher-throughput indexing, better recall, and lower latency at scale than pgvector. 

For full-text search, pg_textsearch, our newest Postgres extension, implements BM25 for modern ranked keyword search optimized for hybrid AI applications alongside pgvectorscale. The current preview release uses an in-memory structure for fast writes and queries. Future releases will add disk-based segments with compression and BlockMax WAND optimization, applying the same battle-tested techniques from production search engines.

Together, these extensions let agents retrieve structured data instantly without leaving Postgres.  

> Using service qilk2gqjuz, analyze user feedback with hybrid search (combining text search and semantic search). Group similar feedback by theme and show counts for each theme, using an ascii bar chart. First, look at the pg_textsearch (BM25) and pgvectorscale documentation in the Tiger docs to get the proper syntax, and then use those extensions.

Fast, zero-copy forks

At the core of Agentic Postgres is a new copy-on-write block storage layer that makes databases instantly forkable. Every agent can spin up its own isolated environment, a full copy of production data in seconds, without duplicating data (or costs). Every fork is lightweight and efficient, so you only pay for the blocks that change. It’s perfect for experiments, benchmarks, and migrations that can run safely in parallel. 

> Please create a fork of gf868h9j1y using the last snapshot, and then test 3 different indexes that we should create to speed up performance, then delete the fork, and report back on your findings. Before you start run “tiger service fork --help” and “tiger service delete --help” to get the right syntax. Use MCP over psql, using the password from the local keychain.

New CLI and free tier

We’ve also built a new CLI that makes it easy to explore, fork, and build with Agentic Postgres, and we’re launching a free tier so every developer and every agent can get hands-on right away.

This is all launching today. You can try this today with 3 basic commands in your terminal:

# 3 commands to install the Tiger CLI and MCP. That's it!
$ curl -fsSL https://cli.tigerdata.com | sh
$ tiger auth login
$ tiger mcp install

Then just tell your agent to spin up a new free service using MCP, or simply call tiger create service from the command line to get going.

Powered by Fluid Storage

Agentic Postgres is powered by Fluid Storage, our new distributed storage layer. Fluid Storage is built on a disaggregated architecture of a horizontally scalable distributed block store using local NVMe storage, a storage proxy layer that exposes copy-on-write volumes, and a user-space storage device driver.

It’s storage that looks like a local disk to Postgres yet scales like a cloud service.

As a result, Fluid Storage delivers instant forks, snapshots, and automatic scaling (up or down) without downtime or over-provisioning. In benchmark testing, a single volume sustains throughput over 110,000 IOPS, while retaining all of Fluid’s elasticity and copy-on-write capabilities. 

All free services on Tiger Cloud run on Fluid Storage today, so every developer can experience its performance and flexibility firsthand. 

And this is just the start. We’ll dive deeper into each of these (MCP, pg_textsearch, pgvectorscale, forkable databases, Fluid Storage, CLI, free tier) later this week and next. 

Built for Agents and Developers

Agentic Postgres is built for agents, so developers can work on higher level problems. 

Building with and for agents, we’ve learned something simple: agents are not here to replace us. They’re here to elevate us.

Agents take on the mechanical, repetitive work, freeing us to focus on what matters most: architecture, design, creativity, impact. They make us faster, smarter, and enable us to do more ambitious work than we could do alone.  

The myth is that AI will replace developers. The truth is that developers who build with agents will replace those who don’t. 

Agentic Postgres is for developers who want to build with AI. For developers who care more about working applications than disposable demos. For developers who want AI to feel like engineering, not just experimentation.

Today’s launch is just the beginning. There are still some rough edges. We’d love your help sanding them down. But expect more to come: more launches, big and small, in the weeks, months, and years ahead.

Agents are the new developers. Agentic Postgres is their new playground.

Built for Agents. Designed to Elevate Developers.

So let’s build. Together.

Get started today: 

$ curl -fsSL https://cli.tigerdata.com | sh

TL;DR: Eight years ago, we launched Timescale to bring time-series to PostgreSQL. Our mission was simple: help developers building time-series applications.

Since then, we have built a thriving business: 2,000 customers, mid 8-digit ARR (>100% growth year over year), $180 million raised from top investors. 

We serve companies who are building real-time analytical products and large-scale AI workloads like: Mistral, HuggingFace, Nvidia, Toyota, Tesla, NASA, JP Morgan Chase, Schneider Electric, Palo Alto Networks, and Caterpillar. These are companies building developer tools, industrial dashboards, crypto exchanges, AI-native games, financial RAG applications, and more. 

We’ve quietly evolved from a time-series database into the modern PostgreSQL for today’s and tomorrow’s computing, built for performance, scale, and the agentic future. So we’re changing our name: from Timescale to Tiger Data. Not to change who we are, but to reflect who we’ve become. Tiger Data is bold, fast, and built to power the next era of software.

Developers Thought We Were Crazy

When we started 8 years ago, SQL databases were “old fashioned.” NoSQL was the future. Hadoop, MongoDB, Cassandra, InfluxDB – these were the new, exciting NoSQL databases. PostgreSQL was old and boring.

That’s when we launched Timescale: a time-series database on PostgreSQL. Developers thought we were crazy. PostgreSQL didn’t scale. PostgreSQL wasn’t fast. Time-series needed a NoSQL database. Or so they said.

“While I appreciate PostgreSQL every day, am I the only one who thinks this is a rather bad idea?” – top HackerNews comment on our launch (link)

But we believed in PostgreSQL. We knew that boring could be awesome, especially with databases. And frankly, we were selfish: PostgreSQL was the only database that we wanted to use.

Today, PostgreSQL has won. 

There are no more “SQL vs. NoSQL” debates. MongoDB, Cassandra, InfluxDB, and other NoSQL databases are seen as technical dead ends. Snowflake and Databricks are acquiring PostgreSQL companies. No one talks about Hadoop. The Lakehouse has won. 

Today, agentic workloads are here. 

Agents need a fast database. We see this in our customer base: private equity firms and hedge funds using agents to help understand market movements (“How did the market respond to Apple WWDC 2025?”); industrial equipment manufacturers building chat interfaces on top of internal manuals to help field technicians; developer platforms storing agentic interactions into history tables for greater transparency and trust; and so on.

What Started as a Heretical Idea Is Now a Thriving Business 

We have also changed. We met in September 1997, during our first week at MIT. We soon became friends, roommates, even marathon training partners (Boston 1998).

That friendship became the foundation for an entrepreneurial journey that has surpassed even our boldest imaginations. 

What started as a heretical idea is now a thriving business:

• 2,000 customers
• Mid 8-digit ARR, growing >100% y/y
• 200 people in 25 countries
• $180 million raised from top investors
• 60%+ gross margins

Cloud usage is up 5x in the last 18 months, based on paid customers alone.

And that’s only the paid side of the story. Our open-source community is 10x-20x larger. (Based on telemetry, it’s 10x, but we estimate that at least half of all deployments have telemetry turned off.)

TimescaleDB is everywhere. It’s included in PostgreSQL offerings around the world: from Azure, Alibaba, and Huawei to Supabase, DigitalOcean, and Fly.io. You’ll also find it on Databricks Neon, Snowflake Crunchy Bridge, OVHCloud, Render, Vultr, Linode, Aiven, and more.

We Are Tiger Data

Today, we are more than a time-series database. We are powering developer tools, SaaS applications, AI-native games, financial RAG applications, and more. The majority of workloads on our Cloud product aren’t time-series. Companies are running entire applications on us. CTOs would say to us, “You keep talking about how you are the best time-series database, but I see you as the best PostgreSQL.” 

So we are now “Tiger Data.” We offer the fastest PostgreSQL. Speed without sacrifice.

Our cloud offering is “Tiger Cloud.” Our logo stays the same: the tiger, looking forward, focused and fast. Some things do not change. Our open source time-series PostgreSQL extension remains TimescaleDB. Our vector extension is still pgvectorscale. 

Why “Tiger”? The tiger has been our mascot since 2017, symbolizing the speed, power, and precision we strive for in our database. Over time, it’s become a core part of our culture: from weekly “Tiger Time” All Hands and monthly “State of the Tiger” business reviews, to welcoming new teammates as “tiger cubs” to the “jungle.” As we reflected on our products, performance, and community, we realized: we aren’t just Timescale. We’re Tiger. Today, we’re making that official.

This is not a reinvention: it’s a reflection of how we already serve our customers today.

Polymarket uses Tiger Data to track their price history. During the last election Polymarket ramped up 4x when trade volumes were extra high, to power over $3.7 billion dollars worth of trades.

Linktree uses Tiger Data for their premium analytics product, saving $17K per month on 12.6 TB from compression savings. They also compressed their time to launch, going from 2 weeks to 2 days for shipping analytical features.

Titan America uses Tiger Data’s compression and continuous aggregates to reduce costs and increase visibility into their facilities for manufacturing cement, ready-mixed concrete, and related materials. 

Lucid Motors uses Tiger Data for real-time telemetry and autonomous driving analytics. 

The Financial Times runs time-sensitive analytics and semantic search. 

Tiger Is the Fastest Postgres for Modern Workloads

We are building the fastest Postgres: purpose-built for the modern operational workloads where traditional OLTP databases break down. 

Operational workloads that go far beyond simple transactions are now the norm. They require real-time, user-facing analytics over massive high-cardinality datasets, from event streams to time-series to user-level behavioral data. 

As the frontier moves further with agentic applications, the demands grow even more. These systems don’t just read and write: they observe, decide, and act. These AI applications require fast vector search across embeddings, and fast branching of data environments for experimentation and context-sensitive responses.

Tiger is not a fork. It’s not a wrapper. It is PostgreSQL, extended with innovations in the database engine and cloud infrastructure to deliver speed without sacrifice.

How are we so fast? Because of consistent, disciplined engineering efforts to serve customer needs over several years. Here is a non-exhaustive list: 

• Hypertables (2017)
• Native columnar compression (2019)
• Real-time materialized views for faster queries (2020)
• Decoupled compute and storage (2021)
• Tiered Storage to S3 Parquet (2022)
• Vectorized query execution for fast analytics (2023)
• Hybrid row-columnar store for faster queries on recent and historical data (2024)
• Faster vector workloads on PostgreSQL via pgvectorscale (2024)
• 300x faster mutations (updates, upserts, deletes) to compressed columnar data (2024)
• 2500x faster distinct queries, 6x faster point queries on high-cardinality columns (2025)
• Rapid horizontal scaling with load-balanced read replica sets (2025)
• Enhanced high-performance storage up to 64 TB and 32,000 IOPS (2025)

Tiger brings together the familiarity and reliability of Postgres with the performance of purpose-built engines.

We built the fastest PostgreSQL. Not because we wanted to, but because our customers wanted us to.

Building the Modern PostgreSQL for the Analytical and Agentic Era

PostgreSQL has won. The Lakehouse has won. Every application is becoming an analytical application. Agents are here, in production, and need to be fast. The future is hybrid, developers and agents, with better latency and throughput needs.

In this era, modern applications must:

• Handle terabytes and petabytes of data
• Support real-time analytics
• Integrate Gen AI features
• Serve both humans and software agents, across dev, test, and production lifecycles
• Meet sub-second latency and high concurrency expectations
• Scale across operational databases and cost-efficient lakehouses
• Maintain transactional integrity
• Deliver all of this reliably and cost-effectively, because data volumes grow much faster than budgets

Our history to date, our time in this market, our lived experience watching all these changes unfold in real-time screams to us one thing: modern applications need a new kind of operational database. 

One built for transactional, analytical, and agentic workloads. One that also acts as the operational serving layer for the Lakehouse. One built on Postgres.

That is what we are building.

And wow do we have some fun product announcements queued up for the upcoming weeks and months. A more agentic PostgreSQL. A deeper integration with the Lakehouse via Iceberg. A new compressed insert approach yielding 10 million rows per second. A new type of disaggregated storage architecture with zero-copy instant forks and replicas that we are deploying in our cloud for greater performance, as a replacement for EBS. And more.

We can’t wait to show it all to you. But first we had to clearly communicate who we are. We are Tiger Data. 

Come Join Us

Tiger is the Fastest PostgreSQL. The operational database platform built for transactional, analytical, and agentic workloads. The only database platform that provides Speed without Sacrifice.

This is not a rebrand, but a recommitment to our customers, to our developers, and to our core mission.

If this mission resonates with you, come join us. Give us product feedback. Spread the word. Wear the swag. Join the team. 

It’s Go Time. 🐯🚀

For instance, users can create, modify, and delete database objects such as tables, views, or users using psql. They can also execute SQL commands, manage data within the database, and even customize the psql environment.

Since psql is the standard command line interface for interacting with a PostgreSQL or TimescaleDB instance, this article will show you how to install it on a variety of operating systems.

Before You Start

Before you start, you should confirm that you don’t already have psql installed. In fact, if you’ve ever installed Postgres or TimescaleDB before, you likely already have psql installed.

To verify it, open the command line program and type the following:

psql --version

If you haven’t installed psql, here is how to install it on a variety of operating systems.

Install on MacOS Using Homebrew

1. First, install the Brew Package Manager. Homebrew, often called "brew," is a free and open-source software package management system that simplifies software installation on Apple's macOS operating system and Linux.

Homebrew downloads, unpacks, and installs the software and its dependencies in your system. It also keeps track of what it has installed, allowing you to easily uninstall software or upgrade to newer versions when they become available.

2. Second, update brew. From your command line, run the following commands:

brew doctor
brew update
brew install libpq

Next, you will have to symlink psql. Symlinking, or creating a symbolic link, is a process in Unix or Unix-like operating systems (like MacOS) that creates a link to a file or a directory that resides elsewhere in the system. Symbolic links are similar to shortcuts in Windows.

3. The final step is to symlink psql (and other libpq tools) into /usr/local/bin:

brew link --force libpq

Install on Ubuntu 23.10,22.04 and Debian 12

Install on Ubuntu and Debian using the apt package manager:

sudo apt update
sudo apt install postgresql-client

Note: This only installs the psql client and not the PostgreSQL database.

Install Windows 10

We recommend using the installer from PostgreSQL.org.

Last Step: Connect to Your PostgreSQL Server

Let’s confirm that psql is installed:

psql --version

Now, in order to connect to your PostgreSQL server, we’ll need the following connection params:

• Hostname
• Port
• Username
• Password
• Database name

There are two ways to use these params.

Option 1:

psql -h [HOSTNAME] -p [PORT] -U [USERNAME] -W -d [DATABASENAME]

Once you run that command, the prompt will ask you for your password. (Which we specified with the -W flag.)

Option 2:

psql postgres://[USERNAME]:[PASSWORD]@[HOSTNAME]:[PORT]/[DATABASENAME]?sslmode=require

If you are using the Tiger Data dashboard, this is how they look in the Tiger Data UI:

Congrats! Now you have connected via psql.

Related resources: psql + Postgres

• Connect with psql
• Data Processing With PostgreSQL Window Functions
• PostgresSQL extensions
• Manual PostgresSQL configuration and tuning
• Integrate PostgreSQL with Tiger Cloud
• A Guide to Scaling PostgreSQL

About TimescaleDB and PostgreSQL Queries

Now that you've installed psql, you are ready to start easily interacting with your PostgreSQL—or TimescaleDB—database.

TimescaleDB is built on PostgreSQL and expands its capabilities for time series, analytics, and events. It will make your queries faster via automatic partitioning, query planner enhancements, improved materialized views, columnar compression, and much more. Plus, you can scale PostgreSQL for cheap with our multi-tiered storage backend.

If you're running your PostgreSQL database on your own hardware, you can simply add the TimescaleDB extension. If you prefer to try TimescaleDB in AWS, create a free account on our platform today. It only takes a couple of seconds, no credit card required!

FAQs: How to Install psql on Mac, Ubuntu, Debian, Windows

Q: How do I check if psql is already installed on my system? A: You can verify if psql is already installed by opening your command line program and typing psql --version. If you've previously installed PostgreSQL or TimescaleDB, you likely already have psql installed, as it comes bundled with these installations.

Q: How do I install psql on macOS? A: To install psql on macOS, first install the Brew Package Manager, then run brew doctor, brew update, and brew install libpq commands in sequence. Finally, symlink psql into /usr/local/bin by running brew link --force libpq to make the psql command available system-wide.

Q: How do I install psql on Ubuntu or Debian? A: Installing psql on Ubuntu or Debian is straightforward using the apt package manager. Simply run sudo apt update followed by sudo apt install postgresql-client in your terminal. This installs only the psql client without the full PostgreSQL database server.

Q: What's the recommended way to install psql on Windows 10? A: For Windows 10, the recommended approach is to use the official installer from PostgreSQL.org. This installer provides a wizard-based setup that guides you through the installation process and includes psql along with other PostgreSQL tools.

Q: How do I connect to a PostgreSQL server using psql? A: To connect to a PostgreSQL server, you can use either the command format psql -h [HOSTNAME] -p [PORT] -U [USERNAME] -W -d [DATABASENAME]a (which will prompt for password) or the connection string format psql postgres://[USERNAME]:[PASSWORD]@[HOSTNAME]:[PORT]/[DATABASENAME]?sslmode=require. Both methods require your server's hostname, port, username, password, and database name.

Today we are announcing the beta release of TimescaleDB, a new open-source time-series database optimized for fast ingest and complex queries, now available on GitHub under the Apache 2 license.

TimescaleDB is engineered up from PostgreSQL (packaged as an extension) and yet scales out horizontally, which means it supports normal SQL and all of the features you expect from a relational database: JOINs, secondary indexes, complex predicates and aggregates, window functions, CTEs, etc.

Key benefits:

• Looks, feels, speaks just like PostgreSQL, including a normal SQL (not “SQL-like”) query interface. Existing clients, connectors, and BI tools (e.g., Tableau) work out of the box. Designed to be stupidly easy to use. If you know SQL (and especially PostgreSQL), you already know TimescaleDB.
• Scalable. Everyone “knows” that RDBMSs like PostgreSQL do not scale well. We solve that problem, introducing horizontal scale-out, automatic space/time partitioning, and distributed query optimizations for time-series data. Our latest benchmarks consistently show a greater than 15x improvement on inserts versus vanilla PostgreSQL on a dataset of 250 million rows, achieving constant insert throughput as the database grows (135K writes per second per node, where each write is a row of 10 metrics). We expect the insert rate to stay in that ballpark as the dataset grows further.
• Reliable. Even though TimescaleDB is new, we benefit from 20+ years of work in PostgreSQL reliability and tooling. We stand on the shoulders of giants.

(For more technical details, please refer to our documentation.)

In this age of new and shiny open source data projects, something as old as PostgreSQL can seem boring. But sometimes boring is awesome, especially when it’s your database. TimescaleDB is designed to just work, not wake you up at 3am.

If you have any kind of time-series data, and you like SQL/PostgreSQL, then please give TimescaleDB a whirl and let us know how it goes. We appreciate any feedback (and we’re pretty friendly folks).

You can install TimescaleDB via Homebrew, Docker, or from source. More information on GitHub.

But isn’t there already a glut of time-series databases? Did we really have to build yet another one?

Yes.

(Read on, padawan…)

Why build yet another time-series database?

Seems like time-series databases (i.e., databases optimized for data captured over time, for example, sensor data, financial data, DevOps data, etc.) are in vogue these days.

There have been a number of blog posts on the subject over the past few years (including these gems by Baron Schwartz (2014) and Jason Moiron (2015), and a plethora of new open-source time-series databases, each with their own trade-offs.

We can’t read minds, but we imagine that the developers behind each of those projects built their own time-series database because traditional RDBMS (e.g., PostgreSQL, MySQL) didn’t scale for their needs.

That was the same problem we faced a year ago, when we needed a database to store sensor data for the IoT platform we were building at the time. We loved PostgreSQL, but “knew” that it inherently wouldn’t scale for our needs.

We tested some of the options in the list above, and saw that they all scaled pretty well, but sacrificed query power in exchange, and failed to support a number of key SQL capabilities.

So we had a choice: scalability or query power. That made us sad. We needed both.

In particular, we needed:

• Scalable ingest, reads, and deletes. Some of our customers collected data at kilohertz, so we knew our dataset would get large very quickly. We needed inserts, reads, and deletes (in particular, bulk deletes) to perform well, even at scale. (On the other hand, we didn’t need to optimize for updates, as we expected to perform those rarely.)
• Performant complex queries. We needed support for complex predicates (e.g., readings where temperature and cpu are above certain thresholds), non-time based aggregates over a fixed window (e.g., total number of errors by firmware version), multiple aggregates (e.g., group by device type and time), flexible ordering (e.g., top 10 devices by usage), JOINs (e.g., join sensor data with device metadata), etc., at latencies that satisfied our APIs and dashboards.
• Multiple data type options. We wanted floats, integers, strings, booleans, arrays, JSON blobs. Support for geospatial data types as a bonus.
• An easy to use query language. We didn’t want to have to learn a completely new query language and build brand new connectors. We wanted something like SQL. Actually, we wanted SQL.
• A reliable and easy to operate database. We didn’t want to get woken up at 3am because our database crashed (and we sure didn’t want to lose data). We wanted something boring, something that would just work, not something fancy and experimental. We also wanted something with rich tooling and an abundant software ecosystem, so we wouldn’t always be waiting for (or needing to write) the next connector or integration for other systems we were using.

When we looked at this list, we realized that we needed something like PostgreSQL. In fact, if we could only solve the PostgreSQL scalability problem, we’d have the perfect time-series database: scalable, easy to use, and reliable. (PostgreSQL even has support for geospatial data types and queries, via PostGIS.)

Could this be possible? Being a group of computer science PhDs and academics (including one tenured Professor), we decided to find out for ourselves, and determined that the nature of time-series workloads lend themselves to a new database architecture that could offer both scale and SQL.

And then we built it.

And then we benchmarked it, and found that our database outperformed PostgreSQL by more than 15x on inserts on large datasets. In particular, we found that as the dataset size grows, the insert rate for PostgreSQL drops off dramatically, while our insert rate remains high:

Note:

• Each row contains 10 metrics and a timestamp.
• Each batch contains 10,000 rows written at once across any partitions (similar to what one would expect in production, e.g., when consuming data off of a message bus like Kafka).
• This is on an Azure standard DS4 v2 machine (8 cores), SSD (premium LRS storage).

Finally, scale and SQL. This made us happy.

(So why build yet another time-series database? Because we had to.)

Really, scale and normal SQL? (Demo)

Get ready for the world’s most boring database demo, because TimescaleDB’s query language is just normal SQL:

This obviously is just a sample. For the full documentation on what kinds of queries we support, please refer here.

What’s going on behind the scenes

“So what’s the big deal? This looks just like normal PostgreSQL…”

There are actually 5 key things happening behind the scenes:

1. Automatic space-time partitioning: We take advantage of two major attributes of time-series workloads: that all data has a primary key and a timestamp, and that inserts are largely append-only (writes to most recent interval, infrequent updates). This allows us to automatically partition incoming data for a given table by time and space (primary key) into 2D “chunks” (stored internally as PostgreSQL tables), and create new chunks on demand as necessary, all done transparently to the user.
2. Right-sized data chunks: Our engine ensures that chunks are right sized and time-interval aligned to ensure that the multiple B-trees for a table’s indexes can reside in memory during inserts to avoid thrashing. This also allows us to delete data by dropping entire chunks, rather than needing to delete individual rows, thus avoiding expensive vacuuming operations.
3. Distributed query optimizations: When queries arrive, we avoid querying extraneous chunks via constraint exclusion analysis, and then employ different techniques to parallelize the query across the remaining chunks efficiently.
4. The “hypertable” abstraction: All this complexity is hidden from the user behind an abstraction we call a “hypertable”, which provides the illusion of a single table across all space and time (despite the 2D chunking). Inserts are written to the hypertable; the database automatically partitions the data, writes to the appropriate chunk, and creates new chunks if necessary. Similarly, queries are run against the hypertable; the database automatically runs the distributed query optimizations, determines the minimally necessary set of chunks to query, pushes down any further optimizations to these chunks, and returns the appropriate data.
5. Tight integration with PostgreSQL: All this occurs tightly integrated with the PostgreSQL query parser, which allows the database to support the entire spectrum of PostgreSQL commands and then run its own query planner and optimizations.

For example, each of the queries above is running against a hypertable, allowing the database to hide the complexity of the system from the user.

But this just scratches the surface. For more on our technical architecture, take a look at our documentation.

Why this matters: time-series data is sprouting up everywhere

“Fine”, you might say, “you guys built something that only works for your weirdo IoT backend.”

That’s what we thought too. But as we made the rounds talking about our IoT platform, people would respond: “We’re building our own IoT platform, so we can’t use yours. But, tell us more about this time-series database you built?”

Then, they’d add, “You know, forget IoT, we have a lot of time-series data in general. Could your database help there too?”

And strangely, we heard the same thing from our friends in other industries: they had a growing amount of time-series data and needed something better than existing databases.

Eureka. Our time-series database was solving a bigger problem.

We realized that time-series data, which used to be this niche thing within finance and DevOps, was sprouting up everywhere. We realized that fundamental shifts in computing — more sources of data, fatter pipes, cheaper storage — were creating new currents of time-series data streams. And that analyzing these new datasets across time was powerful, enabling us to monitor the present, understand historical trends, troubleshoot the past, predict the future.

We also noticed that even traditional time-series data applications were becoming more complex: e.g., in DevOps, needing to correlate application performance across microservices; in finance, needing to monitor payment transactions and other customer interaction data in real-time.

There was also another trend at work: the resurgence of SQL. Recent posts like these from Percona (March 27, 2017), Baron Schwartz (March 19, 2017), and Paris Kasidiaris (March 13, 2017) capture the sentiment well. The pendulum is swinging back towards boring SQL. In fact, “NoSQL” databases seem to be rebranding themselves to mean “not only SQL”, rather than outright rejecting SQL.

We realized that our database, which sat at the intersection of the “rise of time-series data” and the “resurgence of SQL”, might actually be useful to other people.

That’s why we decided last fall to change directions and go all in on the database. After several months of heads-down work, we just open sourced it last month under the Apache 2 license.

When you might want to consider alternatives

That said, TimescaleDB can’t solve everyone’s problems. In particular, there are 3 time-series scenarios where there may be better alternatives:

• Simple read requirements: When most of your query patterns are simple in nature (e.g., simple key-value lookups, or rollup of a single metric over time).
• Low available storage: When resource constraints place storage at a premium, and heavy compression is required, even at the cost of query power and ease of use. (Although this is an area of active development, and we expect TimescaleDB to improve.)
• Sparse and/or unstructured data: When your time-series data is especially sparse and/or generally unstructured. (But even if your data is partially structured, TimescaleDB includes a JSONB field type for the unstructured part(s). This allows you to maintain indexes on the structured parts of your data combined with the flexibility of unstructured storage.)

Summary

TimescaleDB is the first open source time-series database that offers normal SQL at scale. It acts like a relational database yet scales linearly for time-series data.

TimescaleDB is in active development by a team of PhDs based in New York City, Stockholm, and Los Angeles. A single-node version is currently available for download. A clustered version is in the works.

We scratched our own itch, and hope it now scratches yours. If it does, or you think it might and want to learn more, we’d love to hear from you at hello@timescale.com.

For more:

• Installation instructions on GitHub
• High-level technical overview
• Our Documentation