--- title: "Self-Hosted TimescaleDB or Tiger Cloud: A Framework for the Decision" published: 2026-06-25T09:51:45.000-04:00 updated: 2026-06-25T10:05:28.000-04:00 excerpt: "A practical framework for choosing between self-hosted TimescaleDB and Tiger Cloud: what each path requires, who owns what, and four questions to decide." tags: TimescaleDB, Tiger Cloud authors: Matty Stratton, Hien Phan, Noah Hein, Brandon Purcell --- > **TimescaleDB is now Tiger Data.** _Written by Tiger Data, creators of TimescaleDB, based on what we have observed across thousands of production deployments._ ## The platform ownership question In the accompanying paper, we described how application requirements become operational systems and how those systems accumulate into a platform. Availability, recovery, scale, lifecycle, and governance each arrive as engineering work that must be designed, staffed, and maintained for as long as the application runs. This framework assumes that argument is true. The question here is not whether platform ownership exists. It does. The question is whether your team should own it. Operating TimescaleDB for a production application means owning a platform, not just a database. That platform has a well-defined operational surface: high availability, point-in-time recovery, data lifecycle management, version lifecycle, security governance. The capabilities that make TimescaleDB effective for time-series workloads, including hypertables, Hypercore, continuous aggregates, and retention policies, each introduce a corresponding operational responsibility. Those responsibilities interact, accumulate, and grow as the application grows. Capable teams own this platform every day. The question is whether they should. This piece maps that operational surface, walks through what each path actually entails, and ends with four questions that decide which one fits your team. ## The operational surface, mapped This is what owning the platform actually requires. For each layer, the work is ongoing, not one-time. **Availability.** A production [high-availability architecture](https://www.tigerdata.com/blog/how-timescale-replication-works-enabling-postgres-ha) means a primary, an HA replica, read replicas, and a connection pooler. Replication must be configured deliberately: [synchronous eliminates data loss risk but affects ingest throughput, while asynchronous preserves throughput but introduces a failover lag window](https://www.tigerdata.com/learn/best-practices-for-postgres-database-replication). Silent replication drift is one of the most common ways HA architectures fail to deliver the guarantees they appear to provide. Failover must be automated, tested under conditions that simulate real failure, and integrated with the connection layer. Rolling maintenance, which means promoting a replica before patching the former primary, must be rehearsed before it is needed. Monitoring covers replication health, failover state, connection pool saturation, query latency, disk growth, and background job status. Someone is on call. **Recovery.** [Backup architecture](https://www.tigerdata.com/blog/database-backups-and-disaster-recovery-in-postgresql-your-questions-answered) must deliver the recovery time and recovery point objectives the application actually requires, tested against production-representative data volumes. Restoration procedures must be validated regularly. An untested backup procedure is a hypothesis. **Scale.** As the application grows, the operational architecture must grow with it. [Chunk intervals require tuning](https://www.tigerdata.com/blog/timescale-cloud-tips-testing-your-chunk-size) as ingest rates change. [Retention policies](https://www.tigerdata.com/learn/what-is-data-retention-policy) must stay aligned with compliance and product requirements that evolve. Continuous aggregate refresh policies must be tuned against dashboard freshness requirements and the resource budget available on the primary. None of these is a one-time decision, and none of them stays owned without effort. **TimescaleDB-specific surface area.** Background jobs underlie both [Hypercore](https://www.tigerdata.com/blog/hypercore-a-hybrid-row-storage-engine-for-real-time-analytics) and [continuous aggregates](https://www.tigerdata.com/blog/materialized-views-the-timescale-way). A refresh job that fails does not surface an error to users; it produces stale data. A retention policy that stops running accumulates data past its intended boundary. A columnstore conversion policy set too early or too late affects storage economics and query performance. Detecting silent failures before they cause problems requires active monitoring, not just query execution. **Governance.** Credential rotation, [audit logging, and change management](https://www.tigerdata.com/learn/guide-to-postgresql-security) become load-bearing as the application matures. Long-lived credentials are a risk surface. Audit logs are only useful if someone is watching them and they are integrated into security monitoring infrastructure. Schema changes, retention policy updates, and continuous aggregate configuration changes require staging environment validation and explicit rollback plans. A retention policy update that accidentally shortens the window and drops compliance data cannot be undone. **Lifecycle.** PostgreSQL releases a new major version each year. Running past end-of-life means running without security patches. Minor version patches require only a brief service restart. Major PostgreSQL version upgrades require a coordinated migration process and must be validated against a staging environment that mirrors production in data volume, query workload, continuous aggregate configuration, and Hypercore columnstore state. This work recurs on a roughly annual basis. ## What each path actually entails Most teams will recognize themselves in both columns of the table below. The purpose is not to identify a winner. It is to surface which constraints matter most in your environment. The decision lives in the cases where the table points in both directions, which is why the four questions at the end of this paper exist. | Situation | Self-hosted often makes sense | Tiger Cloud often makes sense | | --- | --- | --- | | Dedicated platform engineering team | ✓ | | | Platform is part of product differentiation | ✓ | | | Strict data residency or sovereignty requirements | ✓ | | | Platform engineers also build application features | | ✓ | | Infrastructure ownership competes with roadmap delivery | | ✓ | | Application is growing faster than operational capacity | | ✓ | ## The self-hosted path Teams that build and operate the full platform themselves are taking on everything described above. The teams that do this well treat the database platform as a first-class engineering product: its own roadmap, its own runbooks, its own on-call rotation, its own quarterly priorities. They have made a deliberate decision that the control and flexibility this path provides is worth the investment. Concretely, that control buys version timing on the team's own schedule rather than a provider's; the freedom to install any PostgreSQL extension and patch the engine directly; deployment into any environment, including air-gapped, on-premises, or sovereign infrastructure a managed service cannot reach; tuning at the operating-system and storage layers; and a cost model with no usage-based metering. For teams whose constraints or economics make these decisive, owning the stack is not overhead. It is the point. This path makes sense when the team has dedicated platform engineering capacity that is not in direct competition with application development, when compliance or data residency requirements constrain where and how the database can be operated, or when the operational scope of the deployment genuinely exceeds what a managed service provides. ## The Tiger Cloud path Tiger Cloud absorbs the infrastructure layer of the operational surface described above. That means high-availability architecture including replica provisioning, replication monitoring, and automated failover; backup infrastructure and point-in-time recovery with validated restore capability; minor and major version upgrades coordinated with maintenance windows; built-in observability for replication health, background job state, storage growth, and query performance; and compute and storage scaling without manual provisioning. What teams retain are the decisions that require understanding the workload: schema design and hypertable configuration, chunk interval tuning, retention strategy, columnstore policy design, continuous aggregate design and refresh policy trade-offs, query optimization, and application-level access control. These are not incidental responsibilities. Getting retention strategy wrong accumulates data or drops it prematurely. Getting continuous aggregate design wrong produces stale dashboards or overloads the primary. Getting chunk intervals wrong creates memory pressure at exactly the moment ingest peaks. Tiger Cloud removes infrastructure ownership. It does not remove workload ownership. Ownership does not disappear when a team moves to a managed service. It moves. Teams that choose this path are not choosing to avoid engineering decisions. They are choosing which engineering decisions they want to continue owning. Teams tend to reach for this path when the database platform is not the product but the application is, when operational capacity is competing directly with feature development, or when the application is growing and they want to concentrate engineering on decisions specific to their application rather than the infrastructure decisions common to every production TimescaleDB deployment. ## Four questions to make the decision Both paths are defensible. Which one is right depends on four questions the team needs to answer honestly about its own situation. **1\. Is platform engineering in direct competition with application development?** If the same engineers who build features are also expected to own replication monitoring, version upgrades, and backup validation, the competition for their time is real and it compounds as the application grows. If the team has dedicated infrastructure capacity that does not compete with application work, self-hosting is more viable. **2\. Do compliance or data residency requirements constrain the infrastructure?** Some regulated industries or sovereign jurisdictions require direct control over where and how data is stored and processed. If those constraints apply, they narrow the managed service options and may require self-hosting regardless of engineering capacity. **3\. Is the platform the product, or is the application the product?** A team building a data infrastructure product for other developers has different incentives than a team building an industrial monitoring application. If the database platform is part of what you sell, owning it deeply may be the right call. If it is infrastructure that supports what you sell, the calculus is different. **4\. What happens if the application doubles?** More data, more users, more retention requirements, and more operational surface. A team that can handle the platform at current scale may not be able to handle it at twice the scale without adding headcount. The honest question is not whether the team can own the platform today. It is whether they want to own it at the scale the application is heading toward. ## The decision The teams that make this decision well do not make it by accident. They have mapped the operational surface honestly, assessed their own capacity and constraints, and chosen the path that lets their best engineers spend their time on the work that actually differentiates the application. Every team owns the application. The question is how much of the platform they want to own alongside it. The teams that answer that question deliberately, not by default, are the ones who end up with the right architecture for where they are actually going. For many organizations, this decision is not permanent. Operating models evolve as teams, workloads, and business requirements change. The goal is not to pick the right path forever. It is to pick the right path for where the application is now and where it is heading. If you want to understand the full operational surface before making this decision, the white paper this piece is built on is [What You're Really Owning When You Self-Host TimescaleDB](https://www.tigerdata.com/blog/self-hosting-timescaledb-platform-ownership). Tiger Data publishes documentation on both paths, including detailed guidance on [self-hosting TimescaleDB and using Tiger Cloud](https://www.tigerdata.com/docs). ## Frequently asked questions ### **Should I self-host TimescaleDB or use Tiger Cloud?** It depends on whether your team should own the operational platform, not just the database. Both run the same TimescaleDB and PostgreSQL. The difference is who carries the ongoing work of availability, recovery, scale, governance, and version lifecycle. Self-host when you have dedicated platform-engineering capacity, strict data-residency requirements, or the platform is part of what you sell. Choose Tiger Cloud when that operational work would compete with building your application. ### **When does self-hosting TimescaleDB make sense?** Self-hosting makes sense when at least one of these is true: you have a dedicated platform-engineering team whose time does not compete with application development; the database platform is part of your product differentiation; compliance or data-residency rules require direct control over where and how data is stored; or your deployment's operational scope genuinely exceeds what a managed service provides. In those cases the control and flexibility of owning the full stack is worth the investment. ### **When does Tiger Cloud make sense?** Tiger Cloud makes sense when the database is infrastructure that supports your product rather than the product itself, when operational capacity is competing directly with feature development, or when the application is growing faster than your team can staff the operational work. It absorbs the infrastructure layer so your engineers can concentrate on the application. ### **What does Tiger Cloud manage, and what do I still own** Tiger Cloud manages the infrastructure layer: high-availability architecture and automated failover, backup and point-in-time recovery with validated restores, coordinated minor and major version upgrades, built-in observability, and compute and storage scaling. You still own the workload decisions that require understanding your data: schema and hypertable design, chunk-interval tuning, retention strategy, columnstore and continuous-aggregate policy design, query optimization, and application-level access control. ### **Does moving to a managed database remove ownership** No. Ownership does not disappear when a team moves to a managed service; it moves. A managed service removes infrastructure ownership but not workload ownership. Teams choosing Tiger Cloud are not avoiding engineering decisions, they are choosing which engineering decisions they want to keep owning. ### **What is the operational surface of self-hosting TimescaleDB?** Self-hosting a production TimescaleDB platform means owning six ongoing areas of work: availability (replicas, failover, connection pooling, monitoring, on-call), recovery (tested backups and point-in-time restores at production volume), scale (chunk intervals, retention, continuous-aggregate refresh policies), the TimescaleDB-specific background jobs behind Hypercore and continuous aggregates, governance (credential rotation, audit logging, change control), and version lifecycle (annual PostgreSQL major upgrades). Each one needs an owner and recurs for as long as the application runs. ### **Is the self-hosted vs. Tiger Cloud decision permanent?** No. Operating models evolve as teams, workloads, and business requirements change. The goal is not to pick the right path forever, it is to pick the right path for where the application is now and where it is heading. Many teams revisit the decision as they scale.