The Best Time-Series Databases Compared (2026)

Originally published in March 2024

Time-series data is one of the fastest-growing data categories. IoT telemetry, application metrics, financial tick data, observability traces: every one of these workloads accumulates data continuously, indexed by time, and demands a database that can keep up.

Purpose-built time-series databases outperform general-purpose databases on write throughput, compression, and time-range queries. But the landscape has shifted significantly since the last generation of TSDB comparisons. InfluxDB shipped a ground-up rewrite. New contenders like QuestDB are pushing ingestion speed benchmarks. And PostgreSQL-based solutions like TimescaleDB have matured into production-grade alternatives that don't force you to leave the SQL ecosystem.

This guide compares 10 time-series databases across ingestion performance, query capabilities, SQL support, scalability, compression, ecosystem, and cost. We drew from publicly available benchmarks, DB-Engines rankings (March 2026), and hands-on engineering experience.

A note on perspective: At the time of writing, TimescaleDB is #4 in the DB-Engines TSDB rankings. We built this comparison to be genuinely useful to engineers evaluating their options, including cases where TimescaleDB isn't the best fit. Every top-ranking competitor page in this space is written by a vendor. We're a vendor too. The difference is we'll tell you when to pick something else.

What Is a Time-Series Database?

A time-series database (TSDB) is a system designed to store, compress, and query data points indexed by time. These are measurements, events, and metrics that accumulate continuously rather than being updated in place.

Unlike general-purpose databases that optimize for random reads and writes, TSDBs optimize for append-heavy workloads, time-range scans, and downsampled aggregations.

Common time-series data includes:

• Server metrics: CPU, memory, disk I/O, network throughput

• Sensor readings: temperature, pressure, vibration, flow rates

• Financial prices: bid/ask/trade data, order book snapshots

• Application events: page views, errors, latency measurements, user actions

The data model is consistent across these use cases: a timestamp, one or more metric values, and metadata tags (device ID, region, service name) that allow filtering and grouping.

When You Need a Dedicated TSDB vs. a General-Purpose Database

General-purpose databases like PostgreSQL or MySQL can handle time-series workloads at small scale. Performance degrades as tables grow beyond tens of millions of rows. Indexing overhead, lack of time-based partitioning, and inefficient compression become bottlenecks.

A dedicated TSDB is worth evaluating when:

• Write volume exceeds thousands of data points per second

• Queries primarily scan time ranges rather than looking up individual records

• Data retention policies (TTL, downsampling) are a requirement

• Storage costs at scale are a concern

The middle ground exists. PostgreSQL-based solutions like TimescaleDB extend a relational database with TSDB capabilities (hypertables, compression, continuous aggregates), giving you time-series performance without abandoning SQL and the PostgreSQL ecosystem.

Not every time-series problem needs a TSDB. If your data volume is modest and you already run PostgreSQL, starting with native PostgreSQL and migrating to Tiger Data when you hit performance limits is a valid path. This is common practice, and several engineering teams on Reddit confirm it works well as a staged approach.

How We Evaluated: Key Criteria for Choosing a TSDB

Different TSDBs optimize for different trade-offs. We evaluated each database across seven criteria that engineers consistently cite as decision factors, drawn from SERP analysis and discussions across r/dataengineering, r/database, and r/devops.

Ingestion Throughput and Write Performance

How many data points per second can the database sustain under realistic workloads? The distinction between synthetic benchmarks and real-world ingestion matters. Real workloads involve tags, out-of-order writes, and concurrent queries running alongside ingestion.

TSDBs like QuestDB and InfluxDB are optimized for millions of writes per second. TimescaleDB can handle updating data at the same speed of Postgres. The writes throughput is relative to benchmarks.

Query Speed and Analytical Capabilities

Time-range queries, aggregations (avg, min, max, percentile), and downsampled rollups are the core TSDB workloads. Sub-second query times on billions of rows is the benchmark.

TimescaleDB's continuous aggregates pre-compute common rollups for near-instant analytical reads. ClickHouse and QuestDB deliver strong query performance through different architectural approaches. Support for ad-hoc analytical queries (GROUP BY, window functions, JOINs) varies widely. SQL-native databases have a clear advantage here.

SQL Support and Query Language

SQL compatibility is one of the most debated topics in TSDB discussions online. Engineers overwhelmingly prefer SQL over proprietary languages like Flux, PromQL, or InfluxQL.

TimescaleDB, QuestDB, ClickHouse, CrateDB, and TDengine all support SQL or SQL-like syntax. InfluxDB uses InfluxQL and SQL (v3). Prometheus uses PromQL. SQL support means easier integration with existing BI tools (Grafana, Metabase, dbt), lower learning curves, and broader hiring pools.

Scalability: Horizontal vs. Vertical

Vertical scaling (bigger machines) is simpler but has limits. Horizontal scaling (sharding across nodes) handles larger workloads but adds operational complexity.

InfluxDB 3.0 and ClickHouse scale horizontally. Tiger Data supports multi-node deployments on Tiger Cloud. Prometheus is single-node by design, with Thanos, Cortex, and Grafana Mimir adding horizontal scaling.

A key question: does horizontal scaling require an enterprise license? InfluxDB historically restricted clustering to enterprise tiers. VictoriaMetrics and TDengine offer free clustering.

Data Retention, Compression, and Storage Efficiency

TSDBs handle data lifecycle through retention policies (auto-delete after N days), downsampling (reduce granularity of older data), and compression (columnar encoding, delta-of-delta, dictionary compression).

TimescaleDB achieves up to 90%+ compression with its columnstore. ClickHouse also uses  columnar storage, with LZ4/ZSTD compression, though ratios vary significantly by workload. InfluxDB's Apache Parquet-based storage in v3 offers strong compression. Storage cost at scale is a major decision factor. A 10x compression difference translates directly to infrastructure spend.

Ecosystem and Integrations

PostgreSQL-based TSDBs (TimescaleDB and its managed edition Tiger Cloud) inherit the entire PostgreSQL ecosystem: extensions, drivers, ORMs, backup tools, monitoring. Prometheus-ecosystem TSDBs (VictoriaMetrics, Mimir) integrate natively with Prometheus-based monitoring stacks.

Open Source Licensing and Cost

License type matters:

• Apache 2.0: permissive (QuestDB, VictoriaMetrics)

• AGPL: copyleft

• BSL/SSPL: source-available but not truly open source

• Proprietary: commercial-only (Kdb+)

InfluxDB 3.0 moved to dual Apache 2.0 + MIT licensing. Tiger Data's core (TimescaleDB) is open source (Timescale License). Managed cloud pricing varies significantly: per-series (InfluxDB), per-GB (Tiger Cloud), compute-based (Amazon Timestream). Understand the pricing model before evaluating.

The Best Time-Series Databases Compared (2026)

InfluxDB

DB-Engines TSDB rank: #1 (score: 20.74)

InfluxDB is the most widely adopted purpose-built time-series database. Version 3.0 is a major rewrite: moved from Go to Rust, with Apache Arrow-based columnar storage, Apache Parquet for persistence, and SQL support alongside InfluxQL.

Strengths: Huge community, extensive documentation, strong cloud offering (Timestream for InfluxDB on AWS), high write throughput. The ecosystem of integrations (Telegraf's 300+ input plugins) is unmatched.

Limitations: InfluxDB 3.0 is still maturing. Community feedback notes stability concerns and feature gaps compared to v1/v2. Historical clustering restrictions (enterprise-only in v1/v2) pushed some teams toward alternatives. Flux language is being deprecated in favor of SQL.

Best for: Teams already invested in the InfluxDB ecosystem and monitoring/observability workloads at scale.

Tiger Data (TimescaleDB)

DB-Engines TSDB rank: #4 (score: 5.42)

TimescaleDB extends PostgreSQL with hypertables, continuous aggregates, and columnstore compression. It's PostgreSQL-native: any tool that works with PostgreSQL works with TimescaleDB. No new query language to learn.

Strengths: Full PostgreSQL compatibility (the entire ecosystem of extensions, drivers, tooling), continuous aggregates for pre-computed rollups, columnstore compression achieving 90%+, JOINs between time-series and relational data, managed cloud offering (Tiger Cloud).

Limitations: Transactional guarantees lower the raw write throughput compared to purpose-built engines like QuestDB for extreme ingest scenarios. PostgreSQL single-node architecture means horizontal scaling requires Tiger Cloud or manual partitioning.

Best for: Teams that already use PostgreSQL, workloads that need fast analytical queries combined with relational flexibility, environments where SQL is a requirement, and use cases that need to JOIN time-series data with business data.

Prometheus

DB-Engines TSDB rank: #2 (score: 8.71)

The standard for Kubernetes and cloud-native monitoring. Prometheus uses a pull-based metric collection model with PromQL as its query language. It's single-node by design, with horizontal scaling handled by Thanos, Cortex, or Grafana Mimir.

Strengths: De facto standard for cloud-native observability. Massive community. Native Kubernetes integration. Excellent alerting rules engine.

Limitations: Not a general-purpose TSDB. Designed specifically for monitoring. Single-node scalability ceiling. PromQL has a learning curve. Not suitable for long-term storage without external solutions.

Best for: Kubernetes monitoring, infrastructure metrics, alerting-first use cases.

ClickHouse

Not categorized as a TSDB in DB-Engines (classified as OLAP), but increasingly used for time-series workloads. Extremely fast analytical queries on large datasets.

Strengths: Fast analytical query performance, handles high-cardinality data well (a common InfluxDB pain point), strong community, ClickHouse Cloud managed offering. SQL-compatible with extensions for time-series operations. Columnar storage with excellent compression.

Limitations: Not optimized for high-frequency append-only writes the way purpose-built TSDBs are. Operational complexity for self-hosted deployments. No native time-series features like continuous aggregates or automated downsampling.

Best for: Large-scale analytics where time-series is one of several workloads, high-cardinality use cases, teams that need fast ad-hoc queries on massive datasets.

QuestDB

DB-Engines TSDB rank: #7 (score: 3.66)

Designed for extreme write performance and low-latency queries. SQL-first approach with a column-oriented storage engine built in Java and C++.

Strengths: Among the fastest ingestion rates in published benchmarks, nanosecond timestamp support (critical for financial data), SQL support, Apache 2.0 license.

Limitations: Smaller ecosystem and community than InfluxDB or TimescaleDB. Limited JOIN support compared to PostgreSQL-based solutions. Cloud offering is newer and less mature.

Best for: Financial tick data, ultra-high-frequency IoT, workloads where raw ingestion speed is the primary requirement.

VictoriaMetrics

DB-Engines TSDB rank: #10 (score: 1.84)

Fast-growing open-source alternative to Prometheus for long-term metrics storage. Supports MetricsQL (PromQL-compatible) and InfluxDB line protocol. Both single-node and cluster versions are free and open source.

Strengths: Excellent compression (often better than Prometheus), free horizontal clustering (unlike InfluxDB's historical enterprise restriction), drop-in Prometheus replacement, low operational overhead.

Limitations: Primarily designed for metrics/monitoring, not a general-purpose TSDB. Smaller community. Less mature than InfluxDB or Prometheus.

Best for: Prometheus users who need long-term storage and horizontal scaling without enterprise licensing costs.

Kdb+

DB-Engines TSDB rank: #3 (score: 7.41)

The incumbent in financial services. Built for high-frequency trading and tick data analysis. Proprietary q programming language. In-memory columnar architecture.

Strengths: Unmatched performance for financial time-series workloads. Decades of production use in banks and hedge funds. Extremely efficient in-memory processing.

Limitations: Steep learning curve (q language), expensive commercial licensing, small community outside finance, not open source.

Best for: Financial institutions processing high-frequency trading data and quantitative research teams already familiar with q/kdb+.

Apache Druid

DB-Engines TSDB rank: #8 (score: 3.50)

Real-time analytics database designed for event-driven data and OLAP-style queries on time-series data. SQL support via Apache Calcite. Column-oriented storage with automatic indexing.

Strengths: Real-time ingestion with immediate queryability, pre-aggregation at ingest time, strong integration with Kafka and streaming pipelines, handles high-cardinality data well.

Limitations: Operationally complex (multiple node types: Historical, MiddleManager, Broker, Coordinator). Steeper learning curve than simpler TSDBs. Not optimized for simple metric storage.

Best for: Real-time analytics on event streams, interactive dashboards on large datasets, teams already running Kafka-based data pipelines.

TDengine

DB-Engines TSDB rank: #9 (score: 2.27)

Open-source TSDB designed for IoT and industrial applications with a focus on edge-to-cloud architecture. SQL-like query language. Free clustering support.

Strengths: Purpose-built for IoT (native MQTT/OPC UA support), free clustering (unlike InfluxDB), automated tiered storage, lightweight enough for edge deployment.

Limitations: Smaller Western community (stronger adoption in Asia-Pacific). Less mature ecosystem. Documentation quality varies.

Best for: IoT deployments, edge computing scenarios, industrial data historian replacements.

Graphite

DB-Engines TSDB rank: #6 (score: 4.51)

One of the original time-series monitoring tools, still widely deployed. Custom query language. Whisper storage backend (fixed-size database files).

Strengths: Simple and well-understood, large legacy install base, Grafana integration.

Limitations: Aging architecture, limited scalability, no SQL support, no compression optimizations comparable to modern TSDBs. Being replaced by Prometheus and VictoriaMetrics in most new deployments.

Best for: Legacy monitoring environments where Graphite is already deployed and migration isn't justified.

Best Time-Series Database by Use Case

Every use case is different, and the "best" database depends on your existing stack, team expertise, data volumes, and query patterns — no single tool wins across the board. The observations below reflect common patterns across teams, not universal rules.

Best for IoT and Sensor Data

IoT workloads are defined by high write volume from thousands or millions of devices, with relatively simple queries: aggregations by device, time range, and location.

TDengine is purpose-built for this. Native MQTT/OPC UA support, edge deployment capability, and free clustering make it a natural fit for industrial IoT.

TimescaleDB is the strongest option when you need to JOIN sensor data with relational business data (customer records, asset metadata, maintenance schedules) in a single query. Teams running PostgreSQL as their primary database can add time-series capabilities without introducing a second system.

For AWS-native teams wanting a fully managed service, note that Amazon Timestream for LiveAnalytics closed to new customers in June 2025. AWS recommends, for new deployments, evaluating Amazon Timestream for InfluxDB, which offers similar managed infrastructure with InfluxDB-compatible ingestion.

Best for Application Monitoring and Observability

Prometheus is the standard for Kubernetes-native monitoring and alerting. For long-term metric storage beyond Prometheus's local retention, VictoriaMetrics is the most cost-effective option with free clustering.

TimescaleDB can be used as a Prometheus long-term storage backend via remote_write, giving teams SQL access to their metrics alongside application data. Yet more commonly, Tiger Cloud offers an endpoint for Prometheus to scrape the metrics from. 

Best for Financial Markets and Trading

Kdb+ remains the gold standard for high-frequency trading. Unmatched in-memory performance for financial tick data, but the steep learning curve and commercial licensing limit its appeal outside finance.

QuestDB is the open-source alternative. Nanosecond timestamps, extremely fast ingestion, and SQL support make it the best option for teams that can't justify kdb+ licensing.

Best for DevOps and Infrastructure Metrics

Prometheus + Grafana is the de facto stack. For teams hitting Prometheus's single-node limits, VictoriaMetrics (free clustering, PromQL-compatible) or Grafana Mimir are the natural next step.

InfluxDB is the strongest alternative if you're not committed to the Prometheus ecosystem, especially with Telegraf's 300+ input plugins for collecting infrastructure metrics.

Best for Large-Scale Analytics

TimescaleDB's continuous aggregates and columnstore compression deliver fast analytical queries on time-series data. Pre-computed rollups mean common dashboards and reports return near-instantly, even on billions of rows. For teams already on PostgreSQL, this is the most natural path to fast time-series analytics without adding a separate system.

ClickHouse is the alternative when the workload extends beyond time-series into general OLAP: ad-hoc exploration across mixed datasets, high-cardinality dimensions, and workloads where time-series is one of several query patterns.

Apache Druid fits when real-time ingestion with immediate queryability is the priority, such as streaming dashboards on event data.

Time-Series Database Features Deep Dive

Time-Based Aggregation and Continuous Queries

Every TSDB needs to answer questions like "what was the average temperature per hour?" The approach varies significantly.

TimescaleDB uses time_bucket() and continuous aggregates:

InfluxDB 3.0 now supports SQL for time-based aggregation alongside InfluxQL. The move away from Flux (which is being deprecated) means teams can write standard SQL for their rollups.

ClickHouse uses materialized views triggered on insert:

ClickHouse's materialized views process data at insert time. This is efficient but means the view definition must exist before data arrives. Tiger Data's continuous aggregates can be created retroactively on existing data.

Automatic Downsampling and Data Retention

As data ages, you often want to reduce its granularity. Per-second data from last week is useful. Per-second data from two years ago usually isn't.

Tiger Data separates compression from retention, giving you independent control over each:

This pattern gives you high-resolution recent data, compressed older data, and long-term aggregated summaries, all managed automatically.

InfluxDB handles retention at the bucket level. Each bucket has a configurable retention period, and data is dropped when it ages out.

Prometheus has a configurable retention period but no native downsampling. Recording rules are the common workaround for pre-computing lower-resolution metrics.

ClickHouse uses TTL with automatic aggregation on expiry:

JOINing Time-Series Data with Business Data

This is one of the most discussed topics in TSDB evaluation threads. Most purpose-built TSDBs (InfluxDB, Prometheus, QuestDB) have limited or no JOIN support. If you need to correlate sensor readings with device metadata, or match application metrics with customer segments, you typically need to denormalize the data at write time or query multiple systems.

TimescaleDB handles this natively because it's PostgreSQL:

No ETL. No denormalization. No second query to a different system. The time-series data and the business data live in the same database, queryable with standard SQL.

ClickHouse supports JOINs but with different performance characteristics. JOIN-heavy workloads can require careful table engine selection and query tuning.

Handling High-Cardinality Data

High cardinality means millions of unique tag combinations: user IDs, device IDs, trace IDs. This is a well-known pain point, particularly for InfluxDB v1/v2, where high cardinality caused significant memory pressure and performance degradation.

ClickHouse handles high cardinality well by design. Its columnar storage and sparse indexing don't penalize unique value counts the way tag-indexed storage engines do.

TimescaleDB's hypertable chunking helps because data is partitioned by time (and optionally by another dimension), limiting the amount of metadata the query planner needs to evaluate for any given time range.

InfluxDB 3.0's new storage engine (Apache Arrow + Parquet) addresses the cardinality problem at the storage layer, but the new architecture is still maturing.

This is one of the most-discussed trade-offs on Reddit and Hacker News when engineers evaluate TSDBs. If your workload has millions of unique series, test your candidates under realistic cardinality before committing.

How to Choose the Right Time-Series Database

As mentioned above, when selecting a time-series database, the right choice depends on your workload, existing stack, and what trade-offs you're willing to make.

If you need PostgreSQL compatibility and SQL: Tiger Data’s TimescaleDB. Full PostgreSQL ecosystem, standard SQL, no new query language. If you're already running PostgreSQL, this is the lowest-friction option.

If you need the largest community and ecosystem: InfluxDB. The most widely adopted TSDB with extensive integrations, documentation, and community support.

If you need Kubernetes-native monitoring: Prometheus. The de facto standard for cloud-native observability with native K8s integration and service discovery.

If you need fast analytical queries on time-series data: TimescaleDB (continuous aggregates and columnstore for pre-computed, compressed analytics) or ClickHouse (raw OLAP speed, especially when time-series is one of several workloads).

If you need maximum ingestion speed: QuestDB. Designed for extreme write throughput with nanosecond precision.

If you need free horizontal scaling for metrics: VictoriaMetrics. PromQL-compatible, free clustering, drop-in Prometheus replacement.

If you need financial tick data performance: Kdb+ (enterprise) or QuestDB (open source).

If you need IoT edge-to-cloud: TDengine. Native MQTT/OPC UA, edge deployment, free clustering.

If you need real-time stream analytics: Apache Druid. Real-time ingestion with immediate queryability, strong Kafka integration.

The decision often comes down to this: do you want a purpose-built TSDB (InfluxDB, QuestDB) or a relational database extended for time-series (TimescaleDB)? Purpose-built engines optimize for raw performance on a narrow workload. Extended relational databases optimize for flexibility, ecosystem, and the ability to query time-series alongside everything else in your stack.

FAQ

What is the best time-series database?

It depends on your workload. InfluxDB has the largest community and ecosystem. TimescaleDB is the best option for teams on PostgreSQL who need SQL and relational flexibility. Prometheus is the standard for Kubernetes monitoring. QuestDB leads on raw ingestion speed. There is no single "best" for every use case.

Which is better, InfluxDB or TimescaleDB (Tiger Data)?

InfluxDB is a purpose-built time-series engine optimized for monitoring and observability. TimescaleDB extends PostgreSQL, so you get full SQL support, JOINs between time-series and relational data, and the entire PostgreSQL ecosystem. Choose InfluxDB if monitoring is your primary workload and you want the largest TSDB community. Choose TimescaleDB if you need SQL, relational queries, or you're already on PostgreSQL.

Is ClickHouse a time-series database?

ClickHouse is classified as an OLAP database, not a TSDB. But its columnar storage, fast aggregation queries, and compression make it a strong option for time-series analytics, particularly when time-series is one of several workloads. It lacks native TSDB features like continuous aggregates and automated downsampling, so you'll build those patterns yourself.

Can I use PostgreSQL for time-series data?

Yes, at moderate scale. Vanilla PostgreSQL handles time-series workloads well up to tens of millions of rows. Beyond that, you'll want time-based partitioning, compression, and specialized indexing. Tiger Data adds these capabilities as a PostgreSQL extension, so you can start with vanilla PostgreSQL and add Tiger Data when you need it without changing your application code.

What is the best time-series database for IoT?

TDengine is purpose-built for IoT with native MQTT/OPC UA support and edge deployment. Tiger Data is the strongest option when you need to JOIN sensor data with business data in a single query. For AWS-native teams wanting a fully managed option, note that Amazon Timestream for LiveAnalytics closed to new customers in June 2025. AWS now recommends that new customers evaluate Amazon Timestream for InfluxDB.

What is the best open-source time-series database?

QuestDB (Apache 2.0) for maximum ingestion speed. VictoriaMetrics (Apache 2.0) for Prometheus-compatible monitoring with free clustering. Tiger Data's core (TimescaleDB) is open source and offers the broadest SQL and ecosystem support. InfluxDB 3.0 is now Apache 2.0 + MIT.

Which time-series database has the fastest ingestion?

QuestDB consistently posts the highest ingestion benchmarks in published tests. InfluxDB 3.0's Rust-based engine is also competitive. Raw throughput numbers vary by hardware, schema complexity, and whether the benchmark includes realistic tagging and concurrent queries.

How do time-series databases handle high-cardinality data?

High cardinality (millions of unique tag values) is a known challenge. ClickHouse handles it well by design through columnar storage and sparse indexing. Tiger Data's hypertable chunking limits the metadata overhead per query. InfluxDB 3.0's new Parquet-based storage addresses the cardinality issues that affected v1/v2. If your workload has high cardinality, benchmark your candidates under realistic conditions.

What is the difference between a time-series database and a relational database?

A relational database (PostgreSQL, MySQL) is designed for general-purpose workloads: random reads, updates, transactions. A TSDB is optimized for append-heavy workloads where data is indexed by time: fast writes, time-range scans, compression, and automated data lifecycle management. TimescaleDB bridges these categories by extending PostgreSQL with TSDB capabilities, thereby eliminating the need for usual tradeoffs other databases require

When should I use a time-series database vs. PostgreSQL?

Start with PostgreSQL if your data volume is modest (under ~50 million rows) and your queries are straightforward. Consider a TSDB when write volume exceeds thousands of points per second, time-range queries slow down, or you need automated retention and compression. TimescaleDB makes this transition seamless because it is PostgreSQL, with time-series functionality added. Read the Understanding Postgres Performance Limits for Analytics on Live Data whitepaper to learn more.

What is downsampling in a time-series database?

Downsampling reduces the granularity of older data to save storage. Per-second readings from last week might be rolled up to per-minute averages. Per-minute data from last year might become hourly summaries.TimescaleDB handles this through continuous aggregates with separate retention policies. ClickHouse uses TTL-based aggregation. Prometheus relies on recording rules as a workaround.

How does a time-series database compress data?

TSDBs use techniques optimized for time-ordered data: delta-of-delta encoding for timestamps, dictionary compression for repeated tag values, and columnar storage that groups similar values for better compression ratios.TimescaleDB achieves 90%+ compression through its columnstore. ClickHouse also uses columnar storage (with LZ4/ZSTD compression). InfluxDB 3.0 leverages Apache Parquet's built-in compression.

Can I use Postgres for Industrial IoT (IIoT), which involves scaling time-series deployments?

For a deep dive technical resource that answers this question, download and read The IIoT PostgreSQL Performance Envelope Tiger Data whitepaper.