Which TimescaleDB edition fits your team when you need time-series analytics on PostgreSQL
Your team has picked PostgreSQL for time-series data and now has to choose which TimescaleDB build to run. The Apache 2 Edition is enough for basic hypertable use, meaning partitioned time-series tables without continuous aggregates, the columnstore, data retention policies or job scheduling. Once any of those features matter to your workload, you need the Community Edition, which the Tiger Data editions page says is the only build that includes them, along with functions such as time_bucket_gapfill. Confirm the feature list against the current editions page before you commit, since it is the vendor's document that sets the boundary.
The license condition decides most of the choice. Under the Timescale License, you can install the Community Edition in your own on-premises or cloud infrastructure and run it internally at no license fee. You cannot offer it to others as a service. The Apache 2 Edition carries no such restriction, so if your business is selling a hosted time-series database to customers, it can be sold as a service under its terms. That right is real and matters for software vendors and managed service providers. For an internal analytics platform, it usually does not apply, and the Community Edition gives you the full feature set without changing your legal position. Have counsel read the TimescaleDB LICENSE file against your intended use, because the file splits licensing by directory and by built file name.
Before you choose, check three things: whether your queries need continuous aggregates or columnstore compression, whether you must enforce retention automatically, and whether you plan to offer the database to external parties. If the answer to the first two is yes and the third is no, plan on the Community Edition and confirm the license terms with your legal team. The one-line install script in the README is for local development and testing only, so production deployments need a proper packaging plan from the start.
Which features each TimescaleDB edition includes
This table compares the capabilities that Tiger Data's editions page assigns to each build, plus the license and service-offering terms. Read the rows for continuous aggregates, the columnstore, retention policies, job scheduling and time_bucket_gapfill first, because those decide whether the Apache 2 Edition can run your workload. Items marked to confirm are not stated in the researched facts and should be checked with Tiger Data before you commit.
| Capability | Apache 2 Edition | Community Edition |
|---|---|---|
| Continuous aggregates | No | Yes |
| Columnstore (Hypercore) | No | Yes |
| Data retention policies | No | Yes |
| Job scheduling | No | Yes |
| time_bucket_gapfill function | No | Yes |
| Core hypertables and PostgreSQL extension | Included, confirm scope with Tiger Data | Included, confirm scope with Tiger Data |
| License for source outside the tsl directory | Apache License 2.0 | Not applicable, see license for tsl code |
| License for code inside the tsl directory | Not applicable | Timescale License |
| Right to offer it as a service | Yes, can be sold as a service | No, cannot be offered as a service under the Timescale License |
What the Timescale License and Apache 2 terms allow
TimescaleDB ships under two licenses in one repository, so the license that applies depends on which files and build you run. The cards separate the code paths, the internal use terms and the service restriction, then list the terms you must confirm in writing before you commit.
Apache 2.0 covers code outside tsl
Source code outside the tsl directory is licensed under the Apache License 2.0. This is the code path the Apache 2 Edition is built from, and it is the only part of the repository you can offer to customers as a hosted service under those terms. Confirm with your legal team which build artifact your deployment pipeline actually produces, because the file names determine which license applies to the binary you run.
Timescale License covers tsl code
Code inside the tsl directory is licensed under the Timescale License, and so is any built shared object file with -tsl in its name. The Community Edition features, including continuous aggregates, the columnstore, retention policies and job scheduling, sit on this side of the line. Treat a Community Edition binary as Timescale-licensed software even though the PostgreSQL extension framework around it is open.
Free internal use on your infrastructure
Under the Timescale License, you can install TimescaleDB Community Edition in your own on-premises or cloud infrastructure and run it for free. This covers running it for your own products, internal analytics and regulated workloads on accounts you control. Check that your planned use is internal in this sense, and record which environments the software will run in so the license position is documented for auditors.
No hosted service on Community Edition
The Timescale License does not permit offering Community Edition as a service to third parties. If your business plan includes a managed database product for customers, a shared analytics platform sold to other organizations, or a reseller arrangement, the Apache 2 Edition is the build to evaluate for that model. Ask counsel to review the boundary between hosting for your own users and providing a service to others.
Apache 2 Edition feature trade-offs
The Apache 2 Edition can be sold as a service, but the Tiger Data editions page states that continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling and functions such as time_bucket_gapfill are available only in the Community Edition. Map each feature your pipelines depend on against both editions before choosing, since choosing the Apache build removes these capabilities rather than deferring them.
Support and update terms to confirm
The supplied terms do not cover support obligations, update commitments, indemnities or warranties for either edition in self-hosted use. Request these in writing from the vendor before production rollout, including what applies to Community Edition builds you run yourself. Ask also whether the license terms change between releases, since the repository is actively released.
When running Community Edition internally is allowed and when a service offer changes the answer
The license question turns on who uses the database and who pays for access to it. Under the Timescale License, you can install TimescaleDB Community Edition in your own on-premises or cloud infrastructure and run it for free, including for your own applications and staff. The license restriction applies when you offer the database as a service to others. The Apache 2 Edition has no such restriction and can be sold as a service. So the first decision is whether the database serves your organization only, or whether customers, partners or affiliates reach it as a product you sell.
*Illustrative example:* a bank runs Community Edition on its own PostgreSQL cluster to store market data for its trading desks and risk reports. Internal use fits the license terms. Now suppose the same team builds a product that gives its corporate clients a hosted time-series API backed by that TimescaleDB instance, billed per client. That offer is a service made available to others, and the Community Edition terms no longer cover it. The team would need to switch to the Apache 2 Edition, which lacks continuous aggregates, the columnstore, retention policies and job scheduling, or agree a different arrangement with the licensor. Plan that boundary before the product launches, not after customers depend on it.
Before you settle the model, have counsel read the LICENSE text in the timescale/timescaledb repository against your specific deployment and commercial plans, including managed-service, reseller and white-label arrangements. Confirm how the license treats your affiliates and contractors who operate the database for you. This page summarizes the license terms for comparison purposes and is not legal advice. Use counsel's written view to set the boundary for the Community Edition, and record that decision alongside the architecture so future product changes trigger a review.
Which edition suits each typical team situation
An internal analytics team that keeps sensor, application or business event data for reporting usually needs the features that the Apache 2 Edition leaves out. Continuous aggregates keep dashboards fast over long history, the columnstore (Hypercore) reduces the cost of storing older chunks, and data retention policies remove data on a schedule without custom scripts. Under the Timescale License, the Community Edition can run in your own on-premises or cloud infrastructure at no license fee, so an internal team generally does not need to pay to use these features.
- Feature fit: Continuous aggregates, the columnstore, retention policies and job scheduling are available only in the Community Edition.
- Internal use: You can install and run the Community Edition in your own infrastructure for free under the Timescale License.
- Service boundary: The license does not allow you to offer the Community Edition as a service to outside parties, so keep it inside the organization.
- Scheduling: Job scheduling is needed for policies to run without manual work, so plan who owns the jobs.
- Operations: You still run PostgreSQL high availability, backups and upgrades yourself.
Confirm with your legal team that every consumer of the data is inside the organization, because that condition is what makes the Community Edition the right choice here.
A platform team that hosts TimescaleDB for other departments or business units sits between internal use and a service. If the internal customers are part of the same legal entity and the platform team provides the database as an internal utility, the Community Edition generally fits, since the license permits running it in your own infrastructure. The answer changes if the platform team bills external parties, serves subsidiaries or partners that the license treats as outside users, or packages the database as a product sold to others.
- Internal utility: Running one shared Community Edition cluster for internal teams stays within what the license allows when the users are internal.
- Chargeback: Internal cost allocation is generally not the same as selling a service, but confirm the wording with counsel.
- Multi-tenant design: Separate schemas, roles and retention policies per team reduce the risk of one team affecting another.
- Upgrade coordination: Each internal team depends on the same extension version, so set a shared upgrade schedule.
- Support path: Decide whether internal teams get support from the platform team or from a vendor.
Before you extend the service past your organization, check the license terms against your exact customer relationships.
A company that sells a managed time-series service to outside customers cannot use the Community Edition for that purpose under the Timescale License. The Apache 2 Edition is the build that can be sold as a service, but it lacks continuous aggregates, the columnstore, retention policies and job scheduling. The product team must decide whether the lost features can be replaced in the application layer, or whether the business needs a commercial agreement that covers the Community Edition for hosting.
- License limit: The Community Edition cannot be offered as a service under the Timescale License.
- Feature gap: The Apache 2 Edition does not include continuous aggregates, the columnstore, retention policies or job scheduling.
- Commercial option: Ask Tiger Data whether it offers terms that permit hosting the Community Edition for customers.
- Managed alternative: Tiger Cloud is a hosted option, with published plans and support levels that you can compare against your own offering.
- Build effort: Replacing retention and aggregation logic in your own code adds ongoing engineering work that should be scoped early.
Get written confirmation of the license position before you publish a service, since this single condition decides which edition you can ship.
A team that only needs automatic time-based partitioning, plain SQL on time-series tables and no aggregation or retention jobs may find the Apache 2 Edition sufficient. Hypertables and the core time-series functions are the main reason to adopt the extension, and the Apache 2 Edition supplies them under a permissive license. The answer changes when the team expects to add aggregates, compression or automated retention later, because switching editions later adds a migration step.
- Core fit: Hypertables for automatic chunking work with the Apache 2 Edition.
- Excluded features: Time_bucket_gapfill and the features listed for the Community Edition are not available in the Apache 2 Edition.
- Growth path: If you expect to need aggregates or retention within a year, the Community Edition may save a later migration.
- Quick start caution: The one-line install script is for local development and testing only, so plan a production install.
- Licensing: The Apache 2 Edition carries no restriction on offering a service.
Confirm which functions your queries use today, because a single missing function can push the team toward the Community Edition.
What each edition costs and which support is included
Does TimescaleDB Community Edition have a software license fee?
The supplied facts do not list a software fee for either edition. Under the Timescale License, you can install TimescaleDB Community Edition in your own on-premises or cloud infrastructure and run it for free, but you cannot offer it as a service. The Apache 2 Edition is also open source. So the cost you pay is the infrastructure, the operator time to run PostgreSQL and the extension, and any support contract you choose to buy. Confirm the current terms with Tiger Data before you commit, especially if your plan includes reselling database capacity.
What does self-hosted TimescaleDB cost to run each year?
The recurring cost is the infrastructure (compute, storage, backups and network) plus the people who operate it, including PostgreSQL high availability, backup testing, minor and major upgrades of both PostgreSQL and the extension, and monitoring. Neither edition adds a per-core or per-node license fee in the supplied facts, so the main drivers are data volume, retention length, replica count and how many hours your team spends on upkeep. Ask your team to estimate those hours before you compare the total against a managed plan.
What are the Tiger Cloud plan prices for managed TimescaleDB?
Tiger Data's pricing page lists the Performance plan from $30 per month, the Scale plan from $36 per month and Enterprise at custom pricing, with a free 30-day trial of Performance. Use these figures only as a reference point for managed hosting, because they cover different infrastructure than your own cloud or data center. Compare them with the full self-hosted cost, including the staff time you would otherwise spend on backups, failover and upgrades, and confirm current prices on the vendor's pricing page before budgeting.
What support does Tiger Cloud include on each plan?
Tiger Cloud includes developer support by email on all plans. 24x7 production support is a paid add-on, and the Enterprise plan includes it with a 1-hour response time for Sev 1 issues, according to Tiger Data's pricing page. Read the written support terms for the plan you choose, because response targets for lower severities and the hours covered may differ. Ask the vendor to confirm what is included in writing before you rely on it for production.
What support must self-hosted TimescaleDB users arrange themselves?
If you run the software yourself, no vendor support comes with the Apache 2 Edition or the Community Edition in the supplied facts, so you must arrange cover for production incidents. The main gaps are 24x7 response, escalation paths for PostgreSQL and extension bugs, and help with upgrades and recovery. You can cover these with an internal on-call rota, a commercial PostgreSQL support contract, or an implementation partner on a retainer. Document who responds to a Sev 1 outage before go-live, not after.
Which support terms should I ask for in a quote?
Ask for the scope in writing, with each deliverable, timeline and exclusion stated before work starts. For implementation, list the PostgreSQL versions and TimescaleDB build covered, the environment (cloud account, data center or air-gapped network), and the handover of runbooks. For ongoing cover, ask for the hours of support, severity definitions, response times for each severity, the escalation path, and whether upgrades of PostgreSQL and the extension are included. Ask whether the price covers one-time setup, recurring retainer work or both.
Which costs stay the same when I move between editions?
Switching between the Apache 2 Edition and the Community Edition changes which features you can use, not the infrastructure or the staff time. The operating work for PostgreSQL stays the same, including backups, point-in-time recovery, high availability and minor updates. Verify that your chosen features, such as continuous aggregates or retention policies, need the Community Edition before you build around them, because that choice affects migration effort later.
How to move from Apache 2 Edition to Community Edition, and back
The sequence confirms which build is installed, aligns PostgreSQL versions, adds the Community build and tests its features before any production data or policies depend on it. The reverse path needs its own checks because Community-only objects will not work on the Apache 2 build.
Confirm the installed build and its library files
The database administrator checks which TimescaleDB build is loaded before changing anything. The license split follows file names: code outside the tsl directory is Apache 2.0, while shared object files with -tsl in their names are under the Timescale License. List the extension version and the shared object files on each database server, and record which databases have the extension installed. Done means you have a written inventory of versions, hosts and databases, and you know whether any Community-only features are already in use. Check whether any policies, continuous aggregates or columnstore settings exist, because those signal Community features in use.
Align the PostgreSQL major version
Before installing, confirm that the PostgreSQL major version on the target server is one the Community build supports for your release, and that the version is still inside its support window. The PostgreSQL versioning policy lists supported majors and end dates, and PostgreSQL 14 is listed as supported only until November 12, 2026. If an upgrade is needed, choose among the options the PostgreSQL upgrading documentation describes: pg_dumpall with restore, pg_upgrade, or logical replication. Logical replication is the option that can keep downtime to several seconds. Pick one method in writing, name the owner, and confirm the result with a test restore on a copy of the data.
Install the Community build on a staging server
The platform engineer installs the TimescaleDB Community Edition package on a non-production PostgreSQL server that matches the production major version and configuration. Use your organization's package source and the vendor's installation guide, not the one-line install script in the README, which the project describes as for local development and testing only. Keep the Apache 2 build installed on production until testing finishes. Done means the server reports the Community build version in its extension catalog and the library loads without errors in the PostgreSQL log.
Enable the extension on a restored copy
Restore a recent copy of production data into the staging cluster, then run the command that creates the extension in each database. Confirm that existing hypertables remain queryable and that the extension version matches the installed package. Review the output of your own catalog queries for hypertables, chunks and jobs, and compare row counts for a sample of tables against production. Done means the restored data matches the source on your chosen checks and the extension loads without errors on the copy.
Test Community-only features before migration
The data owner and an application engineer test the features the Apache 2 build does not include: continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling and time_bucket_gapfill. Run each feature against representative queries and workloads, and time the results against the current setup. Confirm that application code, dashboards and scheduled jobs still behave as expected. Done means a signed test record lists each feature, the expected behavior, the observed result and any open defect, and the owners agree whether the migration can go ahead.
Migrate production and verify hypertables and policies
During an agreed change window, the operations team replaces the production extension library with the Community build, restarts PostgreSQL as your upgrade method requires, and reruns the extension checks on each database. Verify every hypertable, chunk count, retention policy, continuous aggregate refresh and scheduled job against the inventory from the first step. Watch the job history for the first full schedule cycle. Done means each object matches the inventory, all jobs run successfully and a rollback path remains documented until the owners sign off.
Plan the reverse path before relying on Community features
Moving back to the Apache 2 Edition is only safe if no Community-only objects remain in use. Before you rely on continuous aggregates, the columnstore, retention policies or scheduled jobs, the database team must list each object that depends on a Community feature and decide whether it will be dropped, converted or kept. Confirm this with the vendor's editions page and your own test results, since the reverse path depends on those features being absent from the Apache 2 build. Done means a written reverse plan names each dependent object, its owner and the verification query that proves the rollback succeeded.
Confirm backups and restore before sign-off
The database administrator takes a fresh backup before the change and tests a restore to a separate server, both before and after the migration. Keep point-in-time recovery settings consistent with your organization's standard. Verify that the restored database loads the correct extension build and that policies and jobs are present. Done means a restore test succeeded on the post-migration build, the backup retention window is recorded and the change record is closed with the inventory comparison attached.
What you still operate yourself on PostgreSQL either way
Choosing the Apache 2 Edition or the Community Edition does not change who runs the database. Both builds are extensions on PostgreSQL, so you own high availability, backups, point-in-time recovery, and upgrades of both PostgreSQL and the TimescaleDB extension. The edition decision affects which features you can use, not the operating burden underneath them. Before you pick a build, confirm with your own platform team which PostgreSQL major version you will standardize on, and check that the TimescaleDB release you intend to run supports it.
For availability, PostgreSQL offers hot standby servers that serve read-only queries, plus synchronous replication, where a commit waits for standbys, and asynchronous replication, where it does not. The trade-off is durability against write latency, and you must choose it explicitly. PostgreSQL does not detect a failed primary and promote a standby on its own, so automatic failover requires external tooling that your team must select, configure, and test. Connection handling is a separate decision: PgBouncer is a common choice for pooling connections in front of the database, and it needs its own monitoring and failover plan. Confirm how your chosen failover tool handles the extension's background workers during promotion.
Upgrades have two tracks. Minor PostgreSQL releases do not change the storage format, but a major upgrade does, and the documented paths are dump and restore, pg_upgrade, or logical replication, which can work across major versions with only seconds of downtime. The PostgreSQL support windows set the schedule: version 14 is supported until November 12, 2026, version 15 until November 11, 2027, version 16 until November 9, 2028, version 17 until November 8, 2029, and version 18 until November 14, 2030. Plan each upgrade around those dates, test the extension version against the target PostgreSQL version in staging, and confirm the supported combinations with Tiger Data before you change production.
Questions buyers ask before choosing a TimescaleDB edition
Is the Apache 2 Edition enough for our time-series workload?
It depends on which features the workload needs. The Apache 2 Edition covers the core hypertable model, but Tiger Data's editions page places continuous aggregates, the columnstore (Hypercore), data retention policies, job scheduling and functions such as time_bucket_gapfill only in the Community Edition. If your queries rely on rolling aggregates, automated compression or automatic data expiry, the Apache 2 Edition will push that work into your own scripts and scheduled jobs. Map each feature your team uses today against that list before deciding, and treat the result as the starting point for a design review rather than a final answer.
Can we run TimescaleDB Community Edition internally for free?
Yes, for internal use. Under the Timescale License, you can install TimescaleDB Community Edition in your own on-premises or cloud infrastructure and run it at no license charge. The restriction that matters is commercial: you cannot offer Community Edition as a service to third parties. Source code outside the tsl directory is Apache 2.0, and the -tsl shared object files fall under the Timescale License, so a build mix-up can change your obligations. Have counsel confirm how your internal platform, shared services or customer-facing reporting fit the wording before rollout.
Does offering TimescaleDB as a hosted service require the Apache 2 Edition?
Generally, yes. The Timescale License prohibits offering Community Edition as a service, while the Apache 2 Edition can be sold as a service, according to Tiger Data's editions page. If you plan to sell database access, a managed platform or a multi-tenant product built on TimescaleDB, the Apache 2 Edition is the build to evaluate for that model, accepting the feature gaps described above. Also confirm with your legal team how a managed offering that bundles Community Edition features would be classified, since the license line is drawn at the service model rather than at the feature list.
How much effort does moving from the Apache 2 Edition to Community Edition take?
The effort depends on the data volume, how much logic you have built around the missing features, and your downtime tolerance. Because both builds run on PostgreSQL, the schema and SQL largely carry over, but any retention scripts, aggregate refresh jobs or compression routines you wrote for the Apache 2 Edition need to be retired or reconfigured. The PostgreSQL upgrading documentation describes logical replication as a way to move between major versions with only several seconds of downtime, which can inform cutover planning. Ask any implementation partner for a scoped estimate that lists tables, jobs, dashboards and downstream consumers affected.
Can our own team operate TimescaleDB without outside help?
Possibly, if your team already runs PostgreSQL in production. Operating either edition means owning the database itself: backups and point-in-time recovery, high availability, upgrades of both PostgreSQL and the extension, and monitoring. PostgreSQL does not provide software to detect a primary failure and promote a standby, so automatic failover needs external tooling. Teams without that PostgreSQL experience usually need outside help for the first design and the first upgrade cycle. Assess your skills against those tasks, then decide which parts to keep in-house.
What should we request in a scoped quote for a self-hosted TimescaleDB build?
Ask for a written scope that names the edition, the features in use, the environments to build, and the data volumes and retention rules to cover. Request deliverables for installation, hypertable design, backup and recovery testing, upgrade procedures, documentation and handover, plus any migration work. Ask how the quote separates one-time setup from recurring support, and whether ongoing upgrades or testing sit under a retainer. DeployOpen plans and implements self-hosted platforms in your own infrastructure and provides fixed-scope engagements agreed in writing before work starts, so the quote follows directly from that scope.
Which PostgreSQL version should the TimescaleDB build run on?
Choose a PostgreSQL major version that is still supported for the full life of the deployment. According to the PostgreSQL versioning policy, version 18 is supported until November 14, 2030, while version 14 is supported only until November 12, 2026. The TimescaleDB README quick start uses the timescale/timescaledb-ha:pg18 image, but that install script is intended for local development and testing only. Confirm the extension's compatibility with your chosen PostgreSQL major version against the TimescaleDB releases page before you standardize on it.
Does the license decision affect a future move to Tiger Cloud?
It can. Tiger Cloud is Tiger Data's managed service, and its plans list developer support by email on all plans, with 24x7 production support as a paid add-on. Moving a self-hosted Community Edition deployment to a managed service is usually simpler than moving a deployment built around Apache 2 Edition workarounds, because the features your code depends on already exist. Keep the schema and job definitions in version control so either path stays open. Confirm current plan terms with Tiger Data, since its published prices can change.
How DeployOpen scopes an edition decision and its implementation
DeployOpen plans, implements and supports self-hosted platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For TimescaleDB, the first scoping step is the edition decision itself, because it determines which features the build can use and what the client may do with it. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts, and the edition question comes before the architecture and the implementation plan.
Scoping usually starts with a short list of questions. Does the workload need continuous aggregates, the columnstore (Hypercore), retention policies, job scheduling or time_bucket_gapfill? Those features are available only in the Community Edition, so a team that depends on them cannot simply run the Apache 2 Edition. Next, the team must decide whether it will offer TimescaleDB to others as a service, because the Timescale License does not permit that, while the Apache 2 Edition does. Legal counsel should confirm how these terms apply to the client's own use, contractors and affiliates, since DeployOpen does not give license advice.
DeployOpen does not issue certifications, attestations or audit opinions, and it does not interpret licenses as an audit body or counsel would. Its role is to prepare the system, configuration and evidence that an assessor or the client's legal team will review. The client should ask for a written statement of which edition, extension version and PostgreSQL major version are in scope, and should confirm the current license terms directly with Tiger Data before signing a scope. Any scope should also name who maintains the chosen build after go-live, since upgrades of both PostgreSQL and the extension are the client's responsibility unless a retainer covers them.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For TimescaleDB, that means deciding which build fits your license position first, then running the installation, configuration and handover against your own PostgreSQL environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which TimescaleDB build is deployed and which features, such as continuous aggregates or the columnstore, the design relies on.
- We confirm with your counsel how the Timescale License applies to your internal use and any service you plan to offer, before build work begins.
How we build
- We install the chosen TimescaleDB build on your PostgreSQL major version, after checking that version against the PostgreSQL support window.
- Hypertables, retention policies and job schedules are configured and tested against your expected ingest volumes and query patterns.
- Access, authentication and network paths are hardened to your own standards, with backups and restore tests run and recorded.
How we hand over
- Handover documentation covers the installed build, the license position, configuration keys and the upgrade path for both PostgreSQL and the extension.
- Your operators are walked through routine tasks such as checking job status, reviewing retention and performing a minor PostgreSQL update.
- Evidence for compliance assessments is packaged as configuration records and test results, while auditors issue any formal conclusions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
- Upgrade planning follows each PostgreSQL major release and each TimescaleDB release, so extension compatibility is checked before changes reach production.
- Ask us for a written scope and quote that separates one-time build work from any recurring retainer.
