When Tiger Cloud or self-hosted TimescaleDB fits your team
Choose Tiger Cloud when your team wants TimescaleDB running without owning the database operations, and self-host when data location, residency rules or cost require your own infrastructure. The deciding factors are where the data may live, which regulations apply to it, whether your team already runs PostgreSQL well, and how the budget splits between recurring service fees and internal staff time. Tiger Cloud fits teams that lack a database operations function, need a managed service quickly, and can accept that the data sits in Tiger Data's hosted environment under its terms. Confirm the hosting regions and data handling terms directly with Tiger Data before you assume they meet your residency obligations.
Self-hosting fits teams that must keep time-series data inside their own cloud accounts, data centers or air-gapped networks, and that already operate PostgreSQL with confidence. The license matters here. The Community Edition is licensed under the Timescale License, which lets you install and run it for free in your own on-premises or cloud infrastructure, but it does not allow you to offer it as a service. Self-hosting on the Community Edition is therefore for internal use. If your product sells access to a hosted time-series service built on TimescaleDB, the Apache 2 Edition or a managed offering is the path to check first, and your counsel should confirm the terms.
Before committing, ask a clear question of your team: who will carry the pager for backups, high availability, failover and both PostgreSQL and extension upgrades? If the answer is nobody with the skills, a managed plan usually costs less in total than hiring for that work, and the published Tiger Cloud plan prices give a starting point for comparison. If the answer is a platform team already running PostgreSQL, self-hosting keeps costs under your control, but you should price the operating hours honestly and document the upgrade and recovery runbooks before go-live.
How the two hosting models differ on cost, features and support
This table compares what each hosting model charges, which TimescaleDB features each build includes, and what support each path gives you. Read the cost rows as a list of components to price yourself, since the supplied facts give vendor plan prices but no infrastructure or staff figures. The main takeaway is that self-hosting trades a vendor subscription for ownership of operations and the feature set you can run.
| Factor | Tiger Cloud (managed) | Self-hosted TimescaleDB |
|---|---|---|
| License and editions | Managed service on Tiger Data's plans, Performance, Scale and Enterprise | Apache 2 Edition or Community Edition under the Timescale License, chosen per build |
| Published vendor price | Performance from $30 per month and Scale from $36 per month (Tiger Data pricing page); Enterprise is custom | No vendor subscription fee implied by the supplied facts; confirm license terms before deploying |
| Compute and storage | Billed through the plan, confirm what each tier includes with Tiger Data | Your cloud, data center or hardware; you pay the infrastructure directly |
| Features that need Community Edition | Available through the managed service, confirm plan coverage for each feature | Continuous aggregates, columnstore, retention policies, job scheduling and time_bucket_gapfill need Community Edition |
| Support levels | Developer support by email on all plans; 24x7 production support is a paid add-on, included in Enterprise with a 1-hour Sev 1 response | Support comes from your own staff, a vendor agreement or a partner; confirm what you need in writing |
| PostgreSQL version and upgrades | Tiger Data operates the PostgreSQL version it offers; confirm the current version and upgrade schedule | You choose and upgrade PostgreSQL 14 through 18 and the extension yourself, within PostgreSQL's support windows |
| Staff and operating effort | Provider handles much of the day-to-day operation; confirm which tasks remain yours | Your team owns HA, backups, monitoring, upgrades and on-call; these are the largest recurring costs to estimate |
How data location and access change compliance work
Compliance work for a time-series database depends on where the data lives, who can reach the keys and consoles, and which records you must produce yourself. The cards below separate what Tiger Data provides in a managed service from what your team keeps in a self-hosted TimescaleDB deployment. DeployOpen prepares controls and evidence, but independent auditors and certification bodies issue any audit report or certification.
Data residency and regions
In Tiger Cloud, the database runs in a region Tiger Data operates, so your residency position depends on which regions are offered and where backups and replicas are placed. In self-hosted TimescaleDB, you choose the data center, cloud account or air-gapped network yourself. Confirm the available Tiger Cloud regions, backup locations and any sub-processor locations directly with Tiger Data before you write the data location into your register.
Encryption keys and key custody
Ask who generates, stores and rotates the encryption keys protecting data at rest and in transit under each model. A managed provider controls part of that chain, while a self-hosted deployment places it in your key management system. Record the key owner, rotation procedure and recovery path, because an auditor will ask for them in either model.
Administrative and database access paths
In Tiger Cloud, provider staff access follows Tiger Data's own support and operations processes, and your team uses the service console and database roles. Self-hosted access runs through your bastion hosts, PostgreSQL roles and host logins, so every path is yours to log. Map each path a human or service account can take to the data, then decide which paths need approval and recording.
Support access during incidents
Support can change the risk profile of a managed service, since Tiger Cloud includes developer support by email on all plans and 24x7 production support as a paid add-on, with Enterprise including a 1-hour response time for Sev 1 issues. Ask Tiger Data what access its support staff need during an incident, how that access is logged and whether you can require approval for it. Record the answers as part of your third-party access evidence.
Processing terms and certifications
Certifications, audit reports and data processing terms belong to Tiger Data for its managed service and to your organization for the self-hosted stack. Request the current certification statements, data processing agreement and subprocessor list from Tiger Data before procurement, and confirm they cover the Tiger Cloud plan you intend to buy. DeployOpen does not issue audit reports, attestations or certifications, so do not treat any statement from us as a substitute.
Evidence your team must produce
Self-hosting moves more evidence into your own program, including backup restore tests, access reviews for PostgreSQL roles and host accounts, patch records for both PostgreSQL and the TimescaleDB extension, and logs of administrative changes. DeployOpen can plan these controls and prepare the evidence, but your auditor samples what your systems actually produced. Agree the evidence list and retention period in writing before the scope is fixed.
What your team runs yourself in each model
Under self-hosting, the operating work stays with your team, and the largest item is high availability. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a primary failure or notify the standby on its own. You need external failover tooling, its configuration, and a tested runbook, and you own the decision about whether a failover is automatic or manual. Backups and point-in-time recovery are the same story: the continuous archiving and PITR mechanisms are documented, but you must choose the archive target, schedule base backups, and run restore drills. Confirm your recovery time and recovery point objectives against what you can actually rehearse.
Upgrades are the second recurring load, and self-hosting means you run two of them. PostgreSQL minor releases do not change the storage format, so they are executable replacements and a restart, while major upgrades use dump and restore, pg_upgrade, or logical replication. Your PostgreSQL support window also matters: PostgreSQL 14 is supported until November 12, 2026, so a cluster still on 14 needs a plan now. TimescaleDB upgrades must be matched to the PostgreSQL major version you run, so each PostgreSQL move can force an extension move. Pair them in one change window and test the extension version against the new server first.
Tiger Cloud shifts much of this work to the vendor, but the boundary is set by the plan and the support tier, not by the product name. The pricing page lists Performance and Scale plans and an Enterprise plan with custom pricing, and developer email support on all plans, with 24x7 production support as a paid add-on that Enterprise includes with a 1-hour response time for Sev 1 issues. Ask in writing which of failover, backup retention, point-in-time restore, minor and major upgrades, and extension upgrades are performed by Tiger Data, which are your responsibility, and what your own change approval steps are. Treat any item that is not confirmed in that document as yours.
Which tasks land on your team in each model
This table lists the recurring tasks that come with running TimescaleDB and marks who performs each one under Tiger Cloud and under self-hosting. Read it as a checklist of operating work, then check each row against the support level and responsibilities in the Tiger Data pricing and editions documentation before you decide.
| Task | Tiger Cloud | Self-hosted TimescaleDB |
|---|---|---|
| Failover and high availability | Confirm with Tiger Data how failover is configured, tested and reported on your plan | Your team designs it. PostgreSQL has hot standbys and synchronous or asynchronous replication, but it does not detect primary failure, so external failover tooling is your responsibility |
| Backups and restore testing | Confirm backup schedule, retention and point-in-time recovery options in writing | Your team configures continuous archiving and point-in-time recovery, and runs restore tests on a schedule you define |
| PostgreSQL minor upgrades | Confirm with Tiger Data when minor versions are applied and whether you can schedule them | Your team replaces executables and restarts. Minor releases do not change the storage format, but the work and the change window are yours |
| PostgreSQL major upgrades | Confirm the upgrade path and downtime window with Tiger Data before you commit | Your team picks pg_dumpall with restore, pg_upgrade or logical replication. Logical replication can keep downtime to several seconds, but it needs planning and testing |
| Supported PostgreSQL version lifecycle | Confirm which PostgreSQL versions your plan runs and when they change | Your team must move off each version before its end of support, such as PostgreSQL 14 on November 12, 2026 (PostgreSQL versioning policy) |
| TimescaleDB extension upgrades | Confirm extension version timing and compatibility notes with Tiger Data | Your team tests and applies extension releases, such as 2.30.2 published September 29, 2026, against your PostgreSQL version |
| Monitoring and alerting | Confirm which metrics and dashboards the plan exposes to you | Your team selects, runs and tunes monitoring for PostgreSQL, the extension and the host |
| On-call and incident response | Developer support by email is included on all plans. Confirm the 24x7 production support level and response times you need | Your team staffs on-call rotations. Vendor support depends on the contract you hold, if any |
| Security patching and authentication | Confirm the patch cadence and which authentication methods the service exposes | Your team applies OS and PostgreSQL security patches and chooses authentication methods such as SCRAM or certificates |
How to move data between self-hosted and Tiger Cloud
This sequence gives you a tested path for moving TimescaleDB data in either direction, from the feature inventory through a validated cutover. Each step ends with a check you can confirm before moving on.
Inventory extension features and schema objects in use
The platform team lists every TimescaleDB feature the workload depends on, including continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling and functions such as time_bucket_gapfill. Per Tiger Data's editions page, these features are available only in the Community Edition, so any dependency on them rules out the Apache 2 Edition as a target. Record hypertables, compression settings, scheduled jobs and the PostgreSQL version and extension version on both sides. Done when the inventory is signed off by the data owner and the application team.
Confirm license fit for the target
Legal or the license owner checks whether the target build permits the intended use. Under the Timescale License, Community Edition can be installed in your own on-premises or cloud infrastructure and run free of charge, but it cannot be offered as a service. The Apache 2 Edition can be sold as a service. Moving a self-hosted Community Edition workload into Tiger Cloud is a change of hosting model, so confirm the commercial terms with Tiger Data before scheduling any move. Done when a written license position is on file for each direction.
Confirm the supported target and PostgreSQL versions
Platform engineering compares the source and target PostgreSQL major versions and TimescaleDB versions against what the target supports. Check the PostgreSQL versioning policy for end-of-life dates for the version you run today, since PostgreSQL 14 is listed as supported only until November 12, 2026. Ask Tiger Data which PostgreSQL and TimescaleDB versions the managed service runs and whether any inventoried feature behaves differently there. Done when the source and target versions are both on supported lines and the gaps are written down.
Choose the migration path and plan the cutover window
The team selects a method that fits the data volume and the tolerance for write interruption, such as a dump and restore, or logical replication where the source and target allow it. PostgreSQL's upgrading documentation describes logical replication between major versions, but whether that path works with your hypertables, continuous aggregates and extension objects must be confirmed with the vendor and tested. Document the rollback path, who approves the window and how application connections will be redirected. Done when the runbook names the method, the owners and the rollback steps.
Rehearse the migration in a non-production copy
Run the full runbook against a copy of production data in an environment that matches the target as closely as possible. Time each phase on your own hardware and network, because any downtime figure must come from your rehearsal and the vendor, not from this page. Capture errors, dropped objects and any job or policy that did not carry over. Done when the rehearsal completes end to end with the issues logged and resolved or accepted.
Validate row counts, aggregates and query results
Compare row counts per hypertable and time range, checksums or aggregate totals for key metrics, and the output of the most important dashboard and alert queries between source and target. Confirm that scheduled jobs, retention policies and continuous aggregate refreshes run on the target as they did on the source. Check users, roles, authentication methods and network access rules. Done when every validation check matches or each difference has a documented explanation and owner.
Cut over and confirm the rollback window
Freeze writes on the source, apply the final delta, point application connection strings at the target and resume writes. Monitor ingestion lag, error rates and job execution for an observation period agreed in advance. Keep the source intact and read-only until the agreed rollback window closes. Done when the application runs on the target, the validation checks pass in production and the decommissioning of the source is approved in writing.
Document the new operating model and retire the old one
Record who now owns backups, point-in-time recovery, high availability, extension and PostgreSQL upgrades, and support escalation. For self-hosted targets, this includes replication, failover tooling and patch cadence. For Tiger Cloud targets, record which responsibilities the managed service covers and which remain with your team, and confirm this with Tiger Data. Update runbooks and monitoring, then decommission the source according to the retention policy. Done when the operating model is signed off and the old environment is removed or archived.
When data location or cost points to self-hosting
Self-hosting is the better choice when data location is a fixed requirement, not a preference. If residency or sovereignty rules require that time-series data stay in a named jurisdiction, in your own cloud accounts, or in a data center you control, a managed service only fits if its hosting regions and support access meet those rules in writing. The same applies to air-gapped or restricted networks, where Tiger Cloud cannot be reached at all and TimescaleDB must run on infrastructure you operate. Confirm with your compliance lead which controls apply to the data, where backups and logs will be stored, and who can access the database for support. Then check whether a managed plan can meet each point before assuming it cannot.
Existing PostgreSQL skills change the calculation. TimescaleDB is an extension inside PostgreSQL, so a team that already runs PostgreSQL for clustering, replication, backups and upgrades can add the extension without learning a new engine. Be clear about the trade: self-hosting moves high availability, backups, point-in-time recovery and both PostgreSQL and extension upgrades to your team. The PostgreSQL documentation states that automatic failover needs external tools, so budget for that tooling and its testing. The license also sets a boundary. The Timescale License permits you to install and run TimescaleDB Community Edition in your own on-premises or cloud infrastructure for free, but it does not allow you to offer it as a service. If your product sells database access to customers, the Apache 2 Edition is the build to evaluate instead.
Cost structure at scale is the third condition, and it is the one most often estimated wrong. Tiger Cloud's published plans start at $30 per month for Performance and $36 per month for Scale, with Enterprise priced on request, according to the Tiger Data pricing page. Those figures show entry points, not totals at your data volume, so request a quote based on your ingest rate, retention window, storage and support tier. For self-hosting, the recurring costs are your compute, storage, backup storage and the staff time to operate the cluster, while the one-time costs are the initial build and hardening. Ask for the support level you need in writing, because Tiger Cloud's 24x7 production support is a paid add-on, and the Enterprise plan is the one that includes a 1-hour response time for Sev 1 issues. Compare that against the on-call cost you would carry yourself.
What buyers ask before choosing or hiring help
What does self-hosting TimescaleDB cost in staff time and infrastructure?
Self-hosting has no per-seat or per-instance license fee for the Apache 2 Edition or for the Timescale License Community Edition when you run it yourself, so the cost is the infrastructure you provision and the people who run it. Those people are the main recurring cost. Your engineers own high availability, backups, monitoring, patching, and upgrades of both PostgreSQL and the extension, and they pay for the compute, storage, and network that the database uses in your cloud account or data center. The cost rises with the number of environments, the data volume, the recovery targets you set, and how often your team must respond after hours. Tiger Cloud replaces part of that work with a published subscription, and the Performance plan starts at $30 per month and the Scale plan at $36 per month according to Tiger Data's pricing page. Ask any vendor for a quote that separates one-time setup from recurring operating effort, and ask for the support level included in each tier.
How long does migrating from Tiger Cloud to self-hosted TimescaleDB take?
No migration duration is supplied for this comparison, so treat any figure you hear as something to confirm in writing. The time depends on data volume, the number of hypertables and continuous aggregates, the downtime window you can accept, and whether you move the extension edition at the same time as the PostgreSQL version. PostgreSQL offers logical replication, which works between different major versions and can keep downtime to several seconds during a major upgrade, according to the PostgreSQL upgrading documentation. Your plan should also cover validation of queries, retention and compression jobs, and access controls. Ask for a scope that lists each step, the cutover method, the rollback path, and the acceptance tests before work begins.
Which TimescaleDB features need the Community Edition license?
Continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling, and functions such as time_bucket_gapfill are available only in TimescaleDB Community Edition, according to Tiger Data's editions page. The Apache 2 Edition does not include them. Under the Timescale License you can run Community Edition for free in your own on-premises or cloud infrastructure, but you cannot offer it as a service to others. If your product depends on those features and you resell database access, the license terms decide which build you can use. Confirm your exact use with counsel before you commit to an architecture.
Can my team run self-hosted TimescaleDB without outside help?
A team can run it alone if it already operates PostgreSQL in production and has people who can handle replication, backup and restore, and extension upgrades. PostgreSQL does not include automatic failover software, so you must select and operate external tools for it, according to the PostgreSQL failover documentation. Backups rely on continuous archiving and point-in-time recovery, which your team must configure, test, and monitor. Confirm that at least two people can perform a restore drill and a major version upgrade without vendor assistance. If that bench is missing, the gap is a staffing decision that should be priced before the platform choice is final.
What support does each Tiger Cloud tier include?
Tiger Cloud includes developer support by email on all plans, according to Tiger Data's pricing page. 24x7 production support is a paid add-on for the lower plans, and the Enterprise plan includes it with a 1-hour response time for Sev 1 issues. Enterprise pricing is custom. Ask the vendor to confirm the exact response targets, escalation path, and business hours in writing, since support terms can change. Compare these terms with your own on-call coverage, because self-hosting moves that responsibility to your team or to a partner you contract separately.
Do I need a consultant to self-host TimescaleDB?
You do not need a consultant to self-host, but many teams hire one for planning, setup, hardening, or migration when internal skills are thin. DeployOpen plans, implements, hardens, backs up, upgrades, documents, and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades, and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner to show how they will handle HA, backups, and extension upgrades, and who keeps the runbooks after handover.
Which PostgreSQL version should I plan to run?
Choose a version that is still in its support window for the whole period you expect to run it. According to the PostgreSQL versioning policy, version 18 was first released on September 25, 2025 and is supported until November 14, 2030, while version 14 is supported until November 12, 2026. Versions 13 and earlier are unsupported. Minor releases arrive at least every three months and do not change the storage format, so applying them means replacing executables and restarting. Plan a major upgrade before any version reaches end of support, and confirm which PostgreSQL version your TimescaleDB build supports before you choose one.
Which TimescaleDB edition each model runs
The first question is which TimescaleDB build Tiger Cloud runs, and whether that build has the same features as the one you would install yourself. TimescaleDB ships in two builds. The Apache 2 Edition is the source outside the tsl directory and is licensed under Apache License 2.0. The Community Edition adds code under the Timescale License. According to Tiger Data's editions page, continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling and functions such as time_bucket_gapfill are available only in the Community Edition. A team that expects those features on a self-hosted Apache 2 build will find them missing.
The Timescale License permits you to install the Community Edition in your own on-premises or cloud infrastructure and run it for free, but it does not allow you to offer it as a service. That makes internal use the normal self-hosting case, and the restriction matters mainly if you plan to resell database access to customers. Read the license text with your legal team before you build a multi-tenant product on top of it. The Apache 2 Edition has no such restriction, which is why the edition choice is also a licensing decision.
Tiger Data's public materials do not, in the facts available here, state which edition each Tiger Cloud plan runs or whether every Community Edition feature is exposed on every plan. Ask Tiger Data in writing which build and version Performance, Scale and Enterprise run, and map each feature your workload depends on (continuous aggregates, columnstore, retention, scheduled jobs) to a named build. Then confirm the same features exist in the self-hosted build you intend to install, including the version number, before you compare operating costs.
How DeployOpen scopes and runs self-hosted TimescaleDB
This sequence turns a self-hosting decision into a written, fixed-scope plan, a working PostgreSQL and TimescaleDB environment inside your infrastructure, and the runbooks your team needs to operate it afterward. Each step ends with a check you can verify before the next one starts.
Confirm the workload and data location requirements
DeployOpen's team meets your architecture, security and platform owners to record which data must stay in your cloud accounts, data centers or air-gapped network, which TimescaleDB features the workload needs, and which PostgreSQL version and TimescaleDB build you intend to run. Because continuous aggregates, the columnstore, retention policies and job scheduling exist only in the Community Edition under the Timescale License, the build choice is made here, with your legal team reviewing what internal use and any service offering permit. The output is a written requirements summary that both sides sign off on.
Agree the fixed scope in writing
DeployOpen drafts a fixed-scope statement that lists the deliverables, the environments covered, the responsibilities of each party and the timeline agreed before work starts. Ask for line items for high availability design, backup and restore testing, upgrade procedures for both PostgreSQL and the extension, hardening, and documentation. Your procurement team should confirm which items are one-time and which would move to a retainer. The quote follows from this written scope, since DeployOpen does not publish a price list. The step is complete when the scope is signed.
Build the environment in your infrastructure
DeployOpen installs PostgreSQL and TimescaleDB on infrastructure you control, using your provisioning tools and network boundaries. Installation uses the build chosen in the first step rather than the quick-start Docker image or the one-line install script, which the TimescaleDB documentation describes as suitable for local development and testing only. Configuration, extension loading, hypertable creation and connection pooling are documented as they are set. The check is a staging cluster that passes agreed functional tests on hypertables and the features in scope.
Harden access, authentication and replication
DeployOpen configures client authentication for your identity model, choosing among the methods PostgreSQL documents, such as certificate, GSSAPI, LDAP or OAuth, and sets SCRAM for password accounts. It configures replication for the availability target agreed in scope, whether hot standbys with synchronous or asynchronous replication. PostgreSQL does not detect a primary failure on its own, so the scope must name the external failover tool and who operates it. The output is a hardening record and an access matrix that your security team reviews.
Set up backups and prove restores
DeployOpen implements continuous archiving and point-in-time recovery as described in the PostgreSQL documentation, with retention and storage locations that you approve. A backup that has never been restored is not evidence, so the scope includes restore exercises into a separate environment with timings recorded. Ask for the recovery point and recovery time objectives you need to be written into the scope, since these depend on your data and risk owners. The step closes when a documented restore has been completed and signed off.
Document upgrade and patch procedures
DeployOpen writes runbooks for minor PostgreSQL releases, which replace executables and require a restart, and for major upgrades using pg_upgrade, logical replication or dump and restore. The runbooks also cover TimescaleDB extension upgrades, which must be sequenced with the PostgreSQL version your cluster runs. The PostgreSQL versioning policy shows the support windows you must plan around, including the November 2026 end of support for version 14. The check is a rehearsal of one upgrade path in staging, with the runbook amended to match what was observed.
Hand over documentation and agree ongoing support
DeployOpen delivers architecture notes, configuration references, backup and restore records, and operator runbooks to your team, then runs a handover session with the people who will be on call. Ongoing support, upgrades and continuous testing are available as a retainer, and that choice is recorded separately from the fixed-scope project. Ask Tiger Data about its support tiers if you are comparing with Tiger Cloud, since its published plans include developer email support on all plans and 24x7 production support as a paid add-on. DeployOpen is not a Tiger Data partner. The step is complete when your team has accepted the handover in writing.
