Migrate from TimescaleDB
Keep your SQL, your time_bucket queries run unchanged. Move history with a \copy and a curl. Land on portable Parquet with no PostgreSQL to operate, and run analytical queries 4.6x faster.
Every command in the guide was tested against TimescaleDB 2.28.2 and Arc 26.06.3.
Why teams move
TimescaleDB is a good fit for teams that need PostgreSQL with transactional guarantees. For append-heavy analytical workloads, the PostgreSQL foundation becomes the ceiling, on every write and every query.
Query engine
4.6x faster, same SQL
On ClickBench (99.9M rows, 43 queries), Arc records a combined score of ×2.24 vs TimescaleDB's ×10.44, about 4.6x faster, and 6.5x faster on hot runs. And time_bucket() is the same function on both sides, so your dashboards carry over.
Ingestion
11x higher throughput
Arc sustains 19.9M records/sec vs TimescaleDB's 1.81M on the same hardware, about 11x. If you already collect with Telegraf, moving new writes to Arc is a one-block config swap. Custom SQL writers re-target Arc's HTTP API.
Operations
No PostgreSQL to run
Arc is a single Go binary. No extensions to load, no shared_buffers to tune, no chunk management. Data lands in portable Parquet you own and can query in place with any Parquet tool.
Migration in three steps
Export hypertables, load them into Arc, translate the handful of queries that need it. Run both systems in parallel until you trust the new one.
Export each hypertable to CSV
Hypertables export like any table with psql \copy. Convert the timestamp to epoch seconds in the query so it imports cleanly (Arc rejects PostgreSQL's default +00 format).
psql -d mydb -c "\copy (SELECT EXTRACT(EPOCH FROM time)::bigint AS time,
host, usage_idle, usage_user FROM cpu ORDER BY time)
TO 'cpu.csv' WITH (FORMAT csv, HEADER true)"Import into Arc
One command per table. Each hypertable becomes a measurement; Arc infers the schema from the header.
curl -X POST "http://localhost:8000/api/v1/import/csv?measurement=cpu&time_column=time&time_format=epoch_s" \
-H "Authorization: Bearer $ARC_TOKEN" -H "X-Arc-Database: mydb" \
-F "file=@cpu.csv"Translate your queries
time_bucket() is the same on both sides, so most queries do not change at all. Set X-Arc-Database and keep bare table names.
-- Runs unchanged on TimescaleDB and Arc:
SELECT time_bucket(INTERVAL '1 hour', time) AS bucket, avg(usage_idle)
FROM cpu GROUP BY 1 ORDER BY 1;TimescaleDB SQL → Arc SQL
Most SQL ports directly. These are the functions that need a rename or a rewrite, all tested to return identical results.
| TimescaleDB | Arc (standard SQL) |
|---|---|
time_bucket(INTERVAL '5 minutes', time) | time_bucket(INTERVAL '5 minutes', time) (same) |
last(value, time) | arg_max(value, time) |
first(value, time) | arg_min(value, time) |
time_bucket_gapfill() + locf() | generate_series spine + LOCF window |
create_hypertable(), retention policies | not needed (schema-on-write) |
Frequently Asked Questions
Will my TimescaleDB queries work on Arc?
Mostly, yes. Arc runs standard SQL and time_bucket() has the same name and argument order as TimescaleDB, so downsampling queries run unchanged. last(v, time) and first(v, time) map to arg_max(v, time) and arg_min(v, time). The one real porting cost is time_bucket_gapfill(), which you reconstruct with a generated bucket series and a window function.
How do I move my historical hypertable data into Arc?
Export each hypertable to CSV with psql \copy, converting the timestamp to epoch seconds or RFC 3339 in the export query, then import into Arc with POST /api/v1/import/csv. Hypertables export exactly like ordinary tables. This round-trip is documented and tested at docs.basekick.net/arc/migration/timescaledb.
Do my applications need to change to write to Arc?
It depends on how you write today. TimescaleDB uses the PostgreSQL wire protocol, which Arc does not speak, so ongoing writes move to HTTP. If you ingest through Telegraf, it is a one-block config swap to the Arc output plugin. If you write with custom SQL INSERT or COPY, that write path becomes an application change to Arc's HTTP write API.
Do I need PostgreSQL to run Arc?
No. Arc is a single standalone binary with no PostgreSQL dependency, no extensions to load, and no shared_buffers to tune. Your data lands in portable Apache Parquet you can query in place with any Parquet-compatible tool. On ClickBench, Arc runs 4.6x faster on combined score than TimescaleDB.
See the tested, step-by-step guide at docs.basekick.net, or compare the two head-to-head in Arc vs TimescaleDB. Benchmark methodology on benchmark.clickhouse.com.
Ready to handle billion-record workloads?
Deploy Arc in minutes. Own your data in open files on your storage. Use for analytics, observability, AI, IoT, or data warehousing.