Timescale is TigerData now: where to take a time-series workload

Short version: Timescale became TigerData on June 17, 2025, the hosted product is Tiger Cloud, and the Postgres extension is still called TimescaleDB. If your tables are hypertables, we are not your migration path and this post will tell you why in detail rather than burying it. If you are on Tiger Cloud running ordinary Postgres, moving is trivial. If you want managed time-series without an extension license in the middle, the engine we actually host for that job is QuestDB.

This is the rare comparison post where the useful part is the section that talks you out of it. Let us get the naming out of the way first, because the naming is genuinely confusing.

The rebrand, in dates

• June 17, 2025: Timescale, the company, rebranded to TigerData.
• The hosted product is now Tiger Cloud.
• The Postgres extension is still TimescaleDB. It did not get renamed.
• Search intent did not move. People still search "Timescale", still say "we run Timescale", and still land on pages titled Timescale. Two years from now they probably still will.

So you can be running TimescaleDB on Tiger Cloud from TigerData, and every one of those three words is correct at the same time. If you have been confused, you were paying attention.

What Tiger Cloud costs

Verified 2026-08-24 on TigerData's pricing page:

There is a 30-day trial with no card, which is a generous evaluation window and better than most.

There is also a free plan, launched October 2025 under the "Agentic Postgres" banner: 750 MB of storage, database forks, and pgvector. It goes read-only when you pass the storage cap, and TigerData says plainly it is not for production. That last part is honest and I would rather a vendor say it than let people find out.

For comparison, Layerbase Cloud Free is $0 with no card and gives you 2 databases with 5 GB of storage. The free tier draws from 8 Standard engines, Postgres among them. Solo is $5/month and Pro is $15/month, both flat, no meters. Our free tier is bigger on storage and our paid entry is lower, and neither of those facts is the reason you should or should not move. The reason is the next section.

If you use hypertables, we are not your migration path

I want this stated plainly, in its own section, with its own heading, because a vendor comparison that hides its own disqualifying constraint is worthless.

Layerbase cannot host the TimescaleDB extension. This is a licensing constraint, not a technical one, and we decided it on 2026-08-14 after actually reading the license rather than guessing:

• TimescaleDB's core is Apache-2.0. The parts people actually buy Timescale for are not. Compression, continuous aggregates, and hyperfunctions are licensed under the Timescale License (TSL).
• The TSL bars offering those features as a competing managed database service. That is what we would be doing. So we do not.

The practical consequence, which is the part that matters to you: a Tiger Cloud dump expects TimescaleDB to exist on the target. Their own restore documentation has you set timescaledb.restoring=true on the destination, which is not a flag a Postgres without the extension can honor. A hypertable dump restored into a plain Postgres fails. It does not partially work, it does not degrade to a normal table, it fails.

This is not new territory for us. We have said in public before, in the IoT database post, that the Layerbase CLI does not run TimescaleDB. Same reason, same answer, and it applies to the cloud too.

So if your schema is hypertables, continuous aggregates, and compression policies, your realistic options are Tiger Cloud, self-hosting TimescaleDB on your own machine, or another host that has a license arrangement to offer it. Not us. Go read the TimescaleDB docs and pick from those three. I would rather you find that out from a blog post than from a failed restore at 11pm.

Who can move cleanly

Here is the group this post is actually for, and it is bigger than people expect.

Plenty of Tiger Cloud databases are just Postgres. The team wanted a good managed Postgres, Timescale had one, they signed up, and the hypertable features are either unused or confined to one small table nobody would miss. If your schema has no hypertables, no continuous aggregates, and no compression policies, TimescaleDB is not doing anything for you and the extension is not part of your data.

Check before you assume. From a psql session against Tiger Cloud:

SELECT hypertable_schema, hypertable_name
FROM timescaledb_information.hypertables;

Empty result, and you are an ordinary Postgres user. Rows come back, and re-read the section above.

For the clean case, the move is the usual one. Your Tiger Cloud connection string looks like this:

postgresql://tsdbadmin@<service>.<project>.tsdb.cloud.timescale.com:<port>/tsdb?sslmode=require

Two things worth knowing: TLS is mandatory, so keep sslmode=require, and the password is shown exactly once when the service is created. If you did not save it, rotate it in their console before you plan a migration evening around finding it.

Then it is the boring command, with one flag that matters:

pg_dump "$TIGER_URL" --no-owner --no-acl \
  --exclude-schema='_timescaledb*' \
  | psql "$LAYERBASE_URL"

The schema exclusion drops the extension's internal catalog schemas, which exist even on a database that never created a hypertable. Without it you will get errors about objects that only mean something to an extension the destination does not have.

Create the destination first at layerbase.com/create/postgresql. Free is enough to test the restore before you commit to anything.

The time-series database we actually host: QuestDB

If you came to Timescale because you have time-series data, and you are open to a different engine rather than a different host for the same engine, this is the interesting part.

We host QuestDB, and it is a purpose-built time-series database rather than Postgres wearing a time-series hat. That distinction cuts both ways, and it is worth being clear about the trade:

What you give up. QuestDB is not a general-purpose relational database. If your time-series table joins against eleven normalized tables of application data and half your queries are transactional, a Postgres extension is the better architecture and I am not going to argue otherwise. TimescaleDB's whole pitch is that you do not have to leave Postgres, and that pitch is correct for a lot of teams.

What you get. A column store built for time from the ground up, InfluxDB Line Protocol ingestion for high write volume, and the Postgres wire protocol for queries, so psql, psycopg, pgx, the pg npm package, and Grafana's Postgres data source all work without a custom driver. SAMPLE BY and LATEST ON do the time bucketing that you would otherwise write as date_trunc plus a window function.

There is a practical availability story here too. QuestDB's own self-serve managed cloud is discontinued, and the official path is a sales-gated Enterprise or BYOC product. We wrote that up in Where to run managed QuestDB now, and the short version is that self-serve managed QuestDB is a small market right now. QuestDB on Layerbase is a Performance-class engine, so it needs the Pro plan at $15/month flat and it runs always-on from your plan's reserved pool rather than sleeping, which matters when the JVM would otherwise cold-start in front of your first morning query.

If you are earlier than that and still deciding whether you need a dedicated time-series database at all, What is a time-series database? is the honest version of that question, including the several cases where the answer is "Postgres is fine, add an index, go do something else."

FAQ

Did Timescale get acquired or shut down?

Neither. The company rebranded to TigerData on June 17, 2025. The hosted product is Tiger Cloud and the Postgres extension is still called TimescaleDB. Nothing was discontinued in the rebrand; the names just multiplied.

Can I run TimescaleDB on Layerbase?

No, and it is a licensing constraint rather than a technical one. TimescaleDB's core is Apache-2.0, but compression, continuous aggregates, and hyperfunctions are under the Timescale License, which bars offering them as a competing managed service. So we do not host the extension anywhere: not in the cloud, not in the CLI.

Will my Tiger Cloud dump restore into a plain Postgres?

Not if it contains hypertables. Their restore procedure expects the extension on the destination, including setting timescaledb.restoring=true, which a Postgres without TimescaleDB cannot honor. If your database has no hypertables, exclude the _timescaledb* schemas from the dump and it restores like any other Postgres database.

How do I check whether I actually use hypertables?

Run SELECT hypertable_schema, hypertable_name FROM timescaledb_information.hypertables; against your Tiger Cloud database. An empty result means the extension is not doing anything for your schema and you are free to move anywhere Postgres runs.

What does Tiger Cloud cost?

As of 2026-08-24, Performance starts at $30/month and Scale starts at $36/month, with Enterprise on a custom quote and a 30-day trial that does not need a card. There is also a free plan from October 2025 with 750 MB of storage, forks, and pgvector, which goes read-only past the cap and is explicitly not for production.

What should I use for time-series if not TimescaleDB?

Depends on the workload. If your time-series data is tightly joined to relational application data and you want one database, staying on a Postgres extension is architecturally right. If the time-series data is the workload, a purpose-built engine wins on ingest and on time-bucketed queries, and the one we host is QuestDB, which speaks the Postgres wire protocol for queries so most of your tooling still works.

Honest close

There is a version of this post that pretends TimescaleDB is replaceable by anything with a timestamp column and ends with a signup link. That post would waste your afternoon and eventually your evening, because you would find out at restore time.

So: hypertables stay where hypertables run. That is Tiger Cloud, or your own server, and the trial they offer is long enough to evaluate properly.

If you are on Tiger Cloud running plain Postgres, move it in an afternoon and stop paying for an extension you never used. If you have a genuine time-series workload and you are willing to change engines rather than hosts, QuestDB on Layerbase is the one we would put in front of you, and we will tell you when it is the wrong tool for that too.