Deploy and Host TimescaleDB with PostGIS on Railway

TimescaleDB turns PostgreSQL into a time-series database: hypertables partition by time automatically, time_bucket and continuous aggregates make rollups cheap, and compression cuts storage on old data. PostGIS adds geometry types and spatial indexes. This template ships both in one database, so a row can carry a timestamp and a location and you can query on either.

About Hosting TimescaleDB with PostGIS

This template runs the official timescale/timescaledb-ha image on a pinned stable tag — PostgreSQL 18.4 with TimescaleDB 2.29.1 — with the cluster on a persistent Railway volume. Nothing is rebuilt or forked, so upstream releases and upstream security fixes are what you get.

The image tag matters more than it looks. Timescale publishes several builds of the same version, and only the -all one carries the full extension set including PostGIS; the plain tag would give you Timescale alone. On top of that, the extensions are already created for you — timescaledb, timescaledb_toolkit and postgis are all present in the database on first connect, so create_hypertable and ST_MakePoint work immediately rather than after two CREATE EXTENSION statements you had to know about.

There is no public HTTP endpoint, because nothing here speaks HTTP. The database is reachable two ways: privately at timescaledb.railway.internal:5432 from other services in your project, and publicly through a Railway TCP proxy for psql, pg_dump, Grafana or a GIS client. Remote connections are password-authenticated with SCRAM.

Common Use Cases

Metrics and IoT telemetry: Write millions of sensor or device readings, then aggregate them with time_bucket and continuous aggregates instead of scanning raw rows.
Fleet and asset tracking: Keep position and timestamp in the same table — "where was this vehicle at 14:00, and how far did it travel today" is one query, not two systems.
Product and financial analytics: Retain events at full resolution, compress what is older than a week, and keep everything queryable in plain SQL.

Dependencies for TimescaleDB Hosting

Deployment Dependencies

TimescaleDB 2.29 on PostgreSQL 18
PostGIS 3.6 — geometry types, spatial indexes and functions
A Railway volume mounted at /home/postgres/pgdata
Any PostgreSQL client or driver — this is Postgres, so yours already works

Implementation Details

RAILWAY_RUN_UID=0 runs the container as root. The image declares USER postgres, and a non-root process cannot take ownership of a freshly attached Railway volume, so initdb fails on the first boot. Running as root is safe here specifically because this entrypoint is written for it: it takes ownership of the data directory and then re-executes itself as postgres through gosu before the database starts.

The volume is mounted at /home/postgres/pgdata while PGDATA stays at /home/postgres/pgdata/data, one level below it. Railway creates a lost+found entry at the root of every volume and initdb refuses a non-empty directory, so the cluster has to live in a subdirectory. Note that the path is not the usual /var/lib/postgresql/data — this image keeps its data under the postgres user's home, and mounting the conventional path would leave the database writing to the ephemeral container layer, where it would be lost on the next deploy.

PostGIS is created by a one-shot job that runs alongside the server on startup: it waits for the database to accept connections and issues CREATE EXTENSION IF NOT EXISTS postgis. It is idempotent, and it is detached — if it ever fails, the database still comes up, just without the extension created. timescaledb and timescaledb_toolkit come from the image's own initialisation scripts.

PORT is set to 5432 explicitly because the image exposes three ports — 5432 plus Patroni's 8008 and pgbackrest's 8081, neither of which is used here — and Railway routes by that variable.

The service carries no healthcheck. Railway probes healthchecks from outside over HTTP, and this service has no HTTP endpoint at all, so one could never pass.

Why Deploy TimescaleDB with PostGIS on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying TimescaleDB on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Resources: 1 GB RAM and the 1 GB volume are a comfortable start. Time-series workloads grow on disk rather than in memory, so watch the volume first — it can be grown without downtime, and Timescale's native compression on chunks older than a few days typically buys back most of it. Raise memory when the working set of recent chunks stops fitting in cache, not before.