---
title: "IIoT Database Requirements: Six Things Your Database Must Do"
description: "IIoT database requirements: high-throughput writes, time-based partitioning, 90%+ compression, full SQL joins, and continuous aggregates for production sensor data."
section: "Postgres for IoT"
---

> **TimescaleDB is now Tiger Data.**

Choosing the right IIoT database starts with knowing what the workload actually demands. IIoT systems generate time-stamped sensor data at a volume and velocity that generic databases were not designed for. A standard PostgreSQL instance or a document database can store sensor readings, but at production IIoT scale, the [<u>architecture breaks down</u>](https://www.tigerdata.com/blog/postgres-optimization-treadmill) in predictable ways: write queues back up, query latency climbs, and storage costs compound faster than budgets allow.

The question for most IIoT engineers is not whether to move to a purpose-built time-series database. The question is which one, and what trade-offs come with that choice.

This page covers both. The first section defines the six requirements that separate an adequate IIoT database from a production-ready one. The second answers whether purpose-built IIoT databases (TDengine, Apache IoTDB) offer genuine advantages over a PostgreSQL-based time-series database. Tiger Data makes a database for this use case, so read the requirements section as technology-neutral and evaluate the product section accordingly.

## What makes IIoT data different

Consumer IoT generates intermittent, low-frequency data from a single user or household. A fitness tracker writes a heart rate reading every few seconds. A smart thermostat logs temperature once a minute. The data volumes are manageable with conventional tooling.

IIoT is a different problem. Turbines, compressors, CNC machines, and wellheads generate continuous, high-frequency bursts from thousands of devices in parallel. A single industrial plant can have thousands of sensors. Many of them sample every one to ten seconds. The volume is not a future concern once you scale up; it is present from day one.

Four properties make IIoT data hard to manage at scale:

1. **Volume.** A medium-sized oil and gas facility with 500 to 2,000 sensors sampling every 1 to 10 seconds generates 50,000 to 2,000,000 data points per minute. Each reading is small, but the cumulative ingestion rate is continuous and unrelenting.
2. **Velocity.** PLCs and SCADA systems can burst-write when an event triggers simultaneous readings across hundreds of sensors. A database that handles sustained throughput but stalls under burst conditions will lose data at the worst possible time.
3. **Heterogeneous schema.** A single ingestion stream may include temperature readings, vibration data, pressure values, and status flags with different sampling intervals and data types. Row-oriented databases that expect uniform schema struggle with this variability.
4. **Relational context.** A raw sensor reading (timestamp, device ID, value) is meaningless in isolation. Making it useful requires joining against an asset table (device class, location, equipment group), a maintenance log (last service date, parts replaced), and sometimes a work orders table. Databases that cannot run these joins force engineers to assemble context in application code, which adds latency and failure points.

One more reality most guides skip: many IIoT teams are not starting from scratch. They have years of operational data sitting in a legacy data historian (OSIsoft PI, Aveva, Wonderware) and need a migration path, not just a greenfield recommendation. The architecture patterns section covers both scenarios.

If you're earlier in your research, [<u>A Beginner's Guide to IIoT and Industry 4.0</u>](https://www.tigerdata.com/learn/a-beginners-guide-to-iiot-and-industry-4-0) covers the fundamentals. For a direct database comparison, [<u>The Best Databases for IoT in 2026</u>](https://www.tigerdata.com/learn/how-to-choose-an-iot-database) is a practical side-by-side.

## Six requirements for an IIoT database

These requirements are drawn from common IIoT deployment patterns across manufacturing, oil and gas, and utilities. They are not derived from Tiger Data's feature list.

### 1. High-throughput write ingestion

IIoT systems must sustain continuous high-frequency writes from many devices in parallel, with additional capacity to absorb burst writes when a SCADA event triggers simultaneous readings from hundreds of sensors.

A medium-sized oil and gas facility might have 500 to 2,000 sensors sampling every 1 to 10 seconds, yielding 50,000 to 2,000,000 data points per minute. The database must handle this without write queuing causing data loss. Burst capacity matters as much as sustained throughput. A database that handles the baseline load but stalls under peak conditions is not production-ready for IIoT.

Columnar storage on ingestion (not just at query time) is critical for write performance at this scale. Tiger Data's [<u>Hypercore columnar storage engine</u>](https://www.tigerdata.com/docs/build/how-to/basic-compression) is built around this pattern. In our benchmarks, this architecture handles high-frequency IIoT ingestion without write queuing at the rates described above, though performance will vary based on hardware and schema design.

### 2. Time-based partitioning with automatic chunk management

Sensor data has a natural temporal access pattern: recent data is queried constantly, older data rarely. A database that stores all data in a single flat table cannot efficiently manage this access pattern at IIoT scale. Full-table scans on years of sensor data for a query targeting the last 24 hours are the predictable result.

The requirement: automatic partitioning of data into time-based chunks, with configurable chunk size, and the ability to tier older chunks to cheaper storage without manual intervention.

Tiger Data implements this with hypertables: time-partitioned tables that are queried with standard SQL. No application-layer changes are required. Chunk exclusion ensures that a query for the last 24 hours of vibration readings from compressor unit 42 does not touch data from six months ago, which keeps query latency stable as the total data volume grows.

### 3. Native compression targeting more than 90% reduction

Sensor data is highly compressible. A temperature sensor reading 73.2°F, 73.2°F, 73.3°F, 73.2°F carries almost no unique information across those readings, but a row-oriented database writes each one as a full row. Columnar compression that uses delta encoding and Gorilla encoding for floating-point values can reduce that storage by more than 90%.

Storage costs compound fast when you are storing years of raw sensor data across thousands of devices. Compression also accelerates queries directly, because there is less data to scan.

IIoT deployments should expect compression ratios above 90% on typical sensor data. [<u>Flogistix by Flowco</u>](https://www.tigerdata.com/blog/how-flogistix-by-flowco-reduced-infrastructure-management-costs-by-66-with-tiger-data), which monitors compression equipment across oil and gas operations, achieved 84% compression in production on field equipment sensor data using Tiger Data. [<u>Glooko</u>](https://www.tigerdata.com/blog/how-glooko-turns-3b-data-points-per-month-into-lifesaving-diabetes-healthcare-tiger-data), in a different vertical but with a similar time-series workload, achieved approximately 95%.

Compression algorithms optimized for time-series data (delta encoding, Gorilla encoding for floats) significantly outperform generic gzip or LZ4 on sensor workloads. The database should implement these natively, not require configuration of external compression middleware.

### 4. Full SQL with relational joins

Purpose-built IIoT databases most commonly fall short here, and the reason matters for anyone building real operational workflows.

A raw sensor reading is only useful when you can JOIN it against the context that gives it meaning. Which compressor is device ID 4471? When was it last serviced? Is it in the same equipment group as the unit that failed last month? Answering these questions requires joining the sensor readings table against an assets table, a maintenance log, and potentially a work orders table.

Purpose-built IIoT databases like TDengine and Apache IoTDB typically cannot run these joins natively. TDengine has a SQL-like dialect but lacks full JOIN semantics. Apache IoTDB uses a proprietary query language. The workaround is a separate relational database for the metadata, which means two systems to operate, two query patterns to write, and two points of failure.

Tiger Data runs on PostgreSQL, which handles both the time-series writes and the relational context in a single system using standard SQL. Engineers who already know SQL can query sensor readings and asset metadata in the same statement without learning a new query language.

### 5. MQTT and OPC UA ingestion compatibility

MQTT is the dominant messaging protocol for sensor-to-cloud data pipelines in IIoT. OPC UA is the standard communication protocol for PLCs, SCADA systems, and industrial automation equipment. An IIoT database that requires custom connectors for both is adding integration risk to every deployment.

MQTT ingestion typically flows through Telegraf's MQTT input plugin into a PostgreSQL-compatible database. OPC UA data generally arrives through a SCADA system or OPC UA gateway and can land in the database through the same pipeline. Tiger Cloud is compatible with Telegraf-based MQTT ingestion pipelines and standard PostgreSQL input patterns. A full walkthrough of MQTT-to-PostgreSQL architecture patterns, including the Flogistix oil and gas example, is at [<u>MQTT to PostgreSQL: Architecture, Database Options, and Implementation Paths</u>](https://www.tigerdata.com/learn/mqtt-to-postgresql).

Tiger Cloud does not include a native OPC UA connector. OPC UA data requires a middleware layer (Ignition SCADA with a PostgreSQL connector, Telegraf with an OPC UA input plugin, or a dedicated OPC UA gateway). InfluxDB also supports Telegraf (it is the original Telegraf creator), but InfluxDB's query language fragmentation across versions (InfluxQL in 1.x, Flux in 2.x, SQL-ish API in 3.0) is a real integration consideration for teams that need a consistent query pattern across their pipeline.

### 6. Retention policies and continuous aggregates

IIoT databases accumulate data indefinitely without data lifecycle management. A production system needs configurable retention policies (keep raw data for 90 days, keep hourly rollups for 2 years, archive to cold storage thereafter) and automatic compression and removal at each tier.

Continuous aggregates are the second part of this. Instead of querying raw second-level sensor data to produce a dashboard of one-minute averages, the database should pre-compute and maintain those aggregates automatically, refreshing them incrementally as new data arrives. Tiger Data's [<u>continuous aggregates</u>](https://www.tigerdata.com/docs/reference/timescaledb/continuous-aggregates) work this way. Competing databases either require external ETL or manual materialized views that do not refresh automatically, which means stale data or manual refresh cycles.

A predictive maintenance dashboard for 500 machines querying one-minute averages over 30 days should never touch raw second-level data. Continuous aggregates make that query fast by design: the pre-computed rollup is already there.

[<u>Tiered storage</u>](https://www.tigerdata.com/docs/build/data-management/storage/manage-storage) is the complement to retention policies. Tiger Cloud moves older chunks from high-performance SSD to S3-compatible object storage automatically, without changing the query interface. The data stays queryable via SQL; only the storage tier changes.

## Do you need a specialized IIoT database?

TDengine, Apache IoTDB, and similar databases were purpose-built for IIoT with native support for industrial protocols and device-oriented data models. The real question is whether those design choices outweigh the trade-offs.

**Purpose-built IIoT databases (TDengine, Apache IoTDB)**

Strengths: a native device-oriented data model (TDengine's superTables map naturally to sensor hierarchies), strong native IIoT protocol support, and a write path optimized for high-cardinality device data.

Limitations: proprietary or non-standard query interfaces. TDengine has a SQL-like dialect but lacks full SQL JOIN support. Apache IoTDB uses its own query language. Both have limited ecosystems for analytics, ML, and geospatial extensions. Neither offers managed cloud deployment at the level of mature alternatives, and neither is PostgreSQL-compatible, so existing SQL tooling does not work.

When to choose them: if you are deploying a greenfield IIoT system with no SQL-dependent tooling, no relational metadata, and a team with deep IIoT protocol experience who will own the infrastructure.

**InfluxDB**

Strengths: a mature ecosystem, strong time-series storage, and an extensive Telegraf plugin library for IIoT ingestion patterns.

Limitations: query language fragmentation across versions is a significant operational risk. InfluxQL in 1.x, Flux in 2.x, and a SQL-ish interface in 3.0 each require learning a different paradigm. InfluxDB 3.0 represents a major architectural change. Community reports of migration complexity from 2.x to 3.0 are well-documented, and for IIoT teams who cannot afford downtime, that migration risk is real.

When to consider it: if you are already running a 1.x or 2.x InfluxDB deployment that is working and the migration cost outweighs starting fresh with a PostgreSQL-based system.

**PostgreSQL-based time-series databases (Tiger Data)**

Strengths: full SQL including JOINs, standard PostgreSQL tooling works unchanged, a rich extension ecosystem (pgvector for ML on sensor data, PostGIS for geospatial asset tracking), handles both time-series and relational metadata in one system, a managed cloud option (Tiger Cloud) that eliminates operational overhead, as well as a self-managed, production-grade [<u>Enterprise</u>](https://www.tigerdata.com/timescaledb-enterprise) edition, currently in Early Access. 

Limitations: PostgreSQL is not a protocol-native IIoT database. MQTT and OPC UA ingestion require a middleware layer. If your team needs a database that speaks OPC UA natively without any integration layer, a purpose-built IIoT database may reduce initial setup time.

When to choose Tiger Data: when your team already knows SQL, when your IIoT data needs to JOIN against relational metadata, or when you want a single database handling both sensor storage and business analytics without a second system.

For most IIoT teams, especially those in manufacturing, oil and gas, or utilities with existing SQL-based tooling, the trade-offs of purpose-built IIoT databases are not worth the SQL and ecosystem limitations. A PostgreSQL-based time-series database covers all six requirements above and avoids the two-system problem.

## IIoT database architecture patterns

IIoT databases do not operate in isolation. A production IIoT data pipeline has several moving parts, and the database choice affects every layer.

**Pattern 1: Edge to MQTT broker to Tiger Cloud**

Sensors and PLCs publish data to an MQTT broker (Mosquitto, HiveMQ, or AWS IoT Core). A Telegraf instance subscribes to the broker, buffers data, and writes to Tiger Cloud via the PostgreSQL wire protocol. Tiger Cloud stores raw readings in hypertables, compresses with Hypercore, and serves dashboards via SQL. Grafana is the most common visualization layer for IIoT deployments on this stack.

Continuous aggregates sit between the raw data and the dashboard layer. The dashboard queries the pre-computed rollup rather than raw second-level readings, which keeps query latency stable as the data volume grows.

**Pattern 2: Data historian to Tiger Cloud migration**

Many IIoT teams have years of operational data in a legacy historian (OSIsoft PI, Aveva, Wonderware). Migration is typically the first conversation, not an afterthought.

Historian data is exported via the historian's REST API or ODBC connector, transformed to a time-series row format, and bulk-loaded into Tiger Cloud using COPY or a migration script. The migration does not have to happen all at once. Tiger Cloud can run in parallel with the historian during a phased cutover, with the historian continuing to serve operational interfaces while Tiger Cloud takes over analytics. See [<u>What Is a Data Historian</u>](https://www.tigerdata.com/learn/what-is-a-data-historian) for a full comparison of historian and time-series database architecture.

**Pattern 3: SCADA integration**

SCADA systems (Ignition, Wonderware, FactoryTalk) typically have built-in database connectors. Tiger Cloud is accessible via any PostgreSQL-compatible connector, and most modern SCADA platforms support this natively via JDBC or ODBC.

SCADA operators can query Tiger Cloud from within the SCADA environment using familiar tools, without a separate query interface to learn. Operational data and analytics live in the same system.

**Data retention tiers: hot, warm, and cold**

A practical three-tier approach for IIoT:

- **Hot:** Recent data in high-performance storage, full resolution, fast query access.
- **Warm:** Compressed historical data, tiered to cheaper storage, still queryable via SQL.
- **Cold:** Archived to object storage (S3-compatible), queryable but with higher latency.

Tiger Cloud handles this automatically. Older chunks move from in-database storage to S3-compatible object storage on a configurable schedule, without changing the query interface. The data stays accessible; the storage cost drops.

## IIoT in practice: Mechademy and Flogistix

Here is what this looks like at production scale.

**Mechademy (industrial IoT diagnostics, digital twin infrastructure)**

Mechademy runs diagnostics across industrial equipment using a hybrid digital twin model: simulated equipment behavior is compared against real sensor readings to detect anomalies. Before migrating to Tiger Data, Mechademy used MongoDB. At scale, the workload broke MongoDB's assumptions. Time-series data in a document database required workarounds that added latency and cost.

After migrating: 50x scale increase, 87% reduction in infrastructure costs. The system now processes 10 million diagnostic tests per 30-minute window on equipment data comparable to a 20-machine cluster.

All three of the core requirements show up in this result. The continuous sensor data feeds diagnostic tests at rates that require high-throughput write ingestion. The hybrid diagnostics require joining sensor readings against equipment models. And the 87% cost reduction reflects both storage and compute savings from compressed data. See the full case study: [<u>How Mechademy cut hybrid digital twin infrastructure costs by 87%</u>](https://www.tigerdata.com/blog/how-mechademy-cut-hybrid-digital-twin-infrastructure-costs).

**Flogistix by Flowco (oil and gas compression equipment monitoring)**

Flogistix monitors compression equipment across oil and gas operations. The workload is high-frequency sensor data from field equipment with 99% uptime requirements. An outage means visibility loss on active production assets.

Results: 66% infrastructure management cost reduction, 84% data compression, 99% reliability on the monitoring platform.

Oil and gas compression equipment data is exactly the workload where columnar compression at 80 to 90 percent is achievable in production, not just in benchmarks. The 84% Flogistix figure is a production number on field equipment, not a controlled test. The 99% uptime maps to the reliability requirements IIoT teams cannot compromise on. The 66% cost reduction is what those compression and reliability gains look like at field scale. See the full case study: [<u>How Flogistix by Flowco reduced infrastructure management costs by 66%</u>](https://www.tigerdata.com/blog/how-flogistix-by-flowco-reduced-infrastructure-management-costs-by-66-with-tiger-data).

## Choosing an IIoT database: decision framework

There is no universally correct IIoT database. The right choice depends on your team's SQL familiarity, whether you have relational metadata to join against, and whether you need a managed service or prefer self-hosted infrastructure.

The table below reflects the authors' assessment based on documented capabilities as of May 2026. Test against your specific workload before deciding. Any cell where capabilities may have changed since publication is noted.

| **Requirement** | **Tiger Cloud** | **InfluxDB 3.0** | **TDengine** | **Apache IoTDB** |
| --- | --- | --- | --- | --- |
| High-throughput writes | Yes | Yes | Yes | Yes |
| Time-based partitioning | Yes (hypertables) | Yes | Yes | Yes |
| Native compression (>90%) | Yes (Hypercore) | Yes | Yes | Yes |
| Full SQL with JOINs | Yes (PostgreSQL) | Partial (no JOINs) | Partial (proprietary dialect) | No (proprietary) |
| MQTT ingestion | Via Telegraf | Via Telegraf | Native plugin | Via connector |
| OPC UA ingestion | Via middleware | Via middleware | Via middleware | Via middleware |
| Continuous aggregates | Yes (native) | Limited | No | No |
| PostgreSQL ecosystem | Yes (full) | No | No | No |
| Managed cloud option | Yes (Tiger Cloud) | Yes (InfluxDB Cloud) | Limited | No |
| Historian migration support | Yes | Partial | Limited | Limited |

**Choose Tiger Cloud if:**

- Your team knows SQL and does not want to learn a new query language for time-series data.
- You need to JOIN sensor readings against relational metadata (asset tables, maintenance logs, work orders) without running a second database.
- You are migrating from a data historian and need PostgreSQL-compatible tooling for your existing analytics stack.
- You want a managed cloud service with automated compression, retention, and tiered storage without configuring each layer yourself.
- You are building in oil and gas, manufacturing, or utilities where data volumes are high and your storage budget is constrained.

**Consider a purpose-built IIoT database if:**

- Your team has no SQL experience and the device-oriented data models of TDengine or Apache IoTDB map more naturally to your engineering background.
- You need native OPC UA connectivity without any integration middleware and your deployment timeline does not allow for connector configuration.
- You are prototyping a greenfield system with no legacy tooling to integrate and you want the fastest path to an initial demo.

Before committing to any database for IIoT, read [<u>5 questions to ask before adopting a TSDB for IIoT</u>](https://www.tigerdata.com/blog/5-questions-you-should-ask-before-adopting-a-tsdb-for-iiot). It covers the evaluation criteria that most comparison guides miss.

## FAQ: IIoT database

### What is the best database for IIoT?

The answer depends on your requirements. If your team uses SQL and needs to join sensor data against asset metadata, a PostgreSQL-based time-series database like Tiger Cloud is the most practical choice. If you need native IIoT protocol support and have no SQL dependency, purpose-built options like TDengine or Apache IoTDB are worth evaluating. The six requirements above are the right framework for making this decision for your specific workload.

### Is PostgreSQL good for IIoT?

Standard PostgreSQL is not optimized for high-frequency time-series writes and will develop performance problems at IIoT scale without extensions. Tiger Data’s TimescaleDB extends PostgreSQL with hypertables (time-based partitioning), Hypercore columnar compression, and continuous aggregates. These additions make PostgreSQL production-ready for IIoT workloads while preserving full SQL compatibility and the entire PostgreSQL extension ecosystem.

### What is the difference between a data historian and an IIoT database?

Data historians (OSIsoft PI, Aveva, Wonderware) are proprietary systems purpose-built for industrial process data collection with native OT protocol support and built-in compliance features for regulated industries. Modern IIoT databases are general-purpose time-series databases that accept sensor data via open protocols (MQTT, OPC UA via middleware) and serve it via SQL. Historians are harder to migrate away from, typically more expensive, and less suited for analytics workloads. Modern time-series databases are more flexible, open, and cost-effective for analytics but require more integration work to replace a historian's native protocol connectivity. See [<u>What Is a Data Historian</u>](https://www.tigerdata.com/learn/what-is-a-data-historian) for a full comparison.

### How do I store SCADA data in a database?

Most modern SCADA platforms (Ignition, Wonderware, FactoryTalk) support external database connectors via JDBC, ODBC, or a direct PostgreSQL driver. Tiger Cloud accepts data from SCADA systems that write to a PostgreSQL-compatible endpoint. The typical pattern: configure the SCADA historian to write tag values to Tiger Cloud via the PostgreSQL connector, then query from Grafana or another dashboard layer using SQL. This avoids proprietary SCADA database formats and gives you standard SQL access to operational data.

### Does Tiger Data support MQTT?

Tiger Cloud does not have a native MQTT broker built in, but it integrates cleanly with MQTT-based pipelines via Telegraf. The standard pattern: MQTT broker (HiveMQ, Mosquitto, or a cloud-managed broker), then Telegraf MQTT input plugin, then Tiger Cloud via the PostgreSQL output plugin. Telegraf handles buffering and delivery guarantees; Tiger Cloud handles storage, compression, and querying. This is the same integration pattern used by the Flogistix deployment. See [<u>MQTT to PostgreSQL: Architecture, Database Options, and Implementation Paths</u>](https://www.tigerdata.com/learn/mqtt-to-postgresql) for a full architecture walkthrough.

### What type of database is best for IoT data?

Time-series databases are the most appropriate category for IoT sensor data. They are optimized for sequential writes by timestamp, time-range queries, and compression patterns that take advantage of the slowly-changing nature of sensor readings. Within time-series databases, the choice between purpose-built options (InfluxDB, TDengine) and PostgreSQL-based options (Tiger Data) comes down to whether you need SQL joins for relational context. IIoT workloads almost always do.

### What is the difference between an IoT database and an IIoT database?

The distinction is about workload characteristics more than category. IoT encompasses consumer devices (wearables, smart home) with intermittent, low-frequency data from limited device counts. IIoT covers industrial equipment: compressors, turbines, PLCs, SCADA systems with continuous, high-frequency data from thousands of devices, strict uptime requirements, and often a regulatory compliance dimension (pharmaceutical, energy, utilities). An IIoT database must handle sustained write throughput that most consumer IoT deployments never approach.

### Can I use MongoDB for IIoT?

MongoDB can store sensor data, but its document model is not optimized for time-series writes or time-range queries at IIoT scale. Without time-series indexes and partitioning, MongoDB will accumulate large collections that degrade write and query performance as data grows. The Mechademy case study is a direct example: Mechademy ran IIoT diagnostics on MongoDB before migrating to Tiger Data, achieving 50x scale and 87% cost reduction after the migration. MongoDB is appropriate for IIoT metadata and configuration data but is not recommended as the primary sensor data store at production scale.

### How do I choose between InfluxDB and Tiger Data for IIoT?

If your team is on InfluxDB 1.x or 2.x and the deployment is working, evaluate the migration cost before switching. If you are starting fresh, the key difference is SQL: Tiger Data uses standard PostgreSQL SQL including JOINs; InfluxDB 3.0 uses a SQL-ish interface that does not support full JOIN semantics. If your IIoT data pipeline needs to join sensor readings against relational metadata (asset tables, maintenance logs, work orders), Tiger Data is the more practical choice. Also consider InfluxDB's version fragmentation history: the 1.x to 2.x migration and the 2.x to 3.0 migration each represent significant engineering work. For IIoT deployments that must stay online, that long-term operational risk is worth factoring into the decision.

### How do I store OPC UA data in a database?

OPC UA is a communication protocol for PLCs and industrial automation equipment, not a data transport format. To store OPC UA data in a database, you need an OPC UA client or gateway that reads tag values from the OPC UA server and writes them to your database. Common tools: Ignition SCADA (can write to PostgreSQL-compatible databases natively), Telegraf with an OPC UA input plugin, or a dedicated OPC UA gateway. The output from any of these can write to Tiger Cloud via the PostgreSQL wire protocol. The database does not need to speak OPC UA. The middleware handles the protocol conversion.

### What database should I use for predictive maintenance?

Predictive maintenance requires three things from the database: high-throughput storage of sensor readings at sufficient resolution to detect anomaly precursors, efficient time-range queries to retrieve historical baseline data for model training, and in-database ML support so anomaly detection models can run against the data without exporting to a separate ML platform. Tiger Data covers all three: hypertables for efficient sensor storage, SQL for range queries, and pgvector for vector-based anomaly detection directly in the database. See [<u>IIoT PostgreSQL performance envelope</u>](https://www.tigerdata.com/blog/the-iiot-postgresql-performance-envelope) for a detailed treatment of performance characteristics at IIoT workload scale.

## Start with Tiger Cloud

[<u>Tiger Cloud</u>](https://www.tigerdata.com/cloud) is a fully managed PostgreSQL service with hypertables, Hypercore columnar compression, continuous aggregates, and tiered storage built in. No separate time-series system. No proprietary query language. If your IIoT workload involves SQL, relational metadata, or migration from a legacy historian, Tiger Cloud covers all six requirements above out of the box.

Start a free trial or read the [<u>5 questions to ask before adopting a TSDB for IIoT</u>](https://www.tigerdata.com/blog/5-questions-you-should-ask-before-adopting-a-tsdb-for-iiot) before you decide.