Developers building modern applications start with Postgres. It’s familiar, flexible, and handles transactions well. And every framework, ORM, and service on AWS speaks fluent Postgres.

But as workloads evolve, teams outgrow what vanilla Postgres can comfortably handle. Companies ingest more data, expand real-time analytics, store longer histories, and increasingly support AI-driven features. To accommodate new requirements, developers incorporate specialized data store technologies alongside extended pipelines required to keep data in-sync. Over time, data drifts, operational burden increases and developer velocity tanks as teams spend more time gluing databases together and maintaining complex architectures rather than building new applications.

Developers on AWS want a data layer that unifies transactional, analytical and agentic workloads on top of Postgres and integrates seamlessly within the broader AWS ecosystem.

That’s why we’re partnering with AWS: to jointly solve data fragmentation and deliver the unified data infrastructure developers have been asking for. Through our Strategic Collaboration Agreement announced last week, we’re working with AWS to provide this unified infrastructure to every team building modern applications.

In this blog post, we’re showing the incredible progress we have made over the last 12 months to make this architecture native to AWS including the announcement of two new releases: Tiger Lake public beta and S3 Connector GA.

Postgres, Extended for Modern Workloads on AWS

Developers on AWS already rely on Postgres to power their operational systems. Tiger Data builds on that foundation by extending Postgres to support time-series, vector and full-text search, advanced analytics, and tight lakehouse integration, all while fitting naturally into the AWS ecosystem through our growing collaboration.

The result is Postgres that does everything developers wish Postgres could do, without introducing new query languages, new operational paradigms, or new systems to manage.

At the core of this extended engine are four pillars:

TimescaleDB brings a purpose-built time-series engine directly into Postgres. It handles massive ingest rates, automatic partitioning, hybrid row–column storage with 90%+ compression, SIMD-accelerated scans, incremental materialized views, and keeps recent data fast while automatically tiering older data to Amazon S3. It also includes Hyperfunctions, a rich set of SQL analytics functions for things like statistical aggregates, percentile approximations, gap-filling, and downsampling, so teams can run advanced time-series analytics directly in Postgres without external systems or pipelines.

pgvectorscale introduces high-performance vector search with a DiskANN index, supporting large, high-dimensional embedding workloads with fast filtering and optimized storage. Instead of deploying a separate vector database, developers can store embeddings alongside time-series and relational context, enabling AI-driven features on top of unified data.

pg_textsearch provides modern full-text search powered by a BM25 ranking model and a memtable architecture that enables fast incremental indexing and low-latency search, right inside Postgres.

Layered on top of these engines is deep integration with the AWS platform for secure connectivity, streaming and batch ingest, observability, analytics, AI and billing, which has been a key area of focus for us over the last 12 months.

A Year of Deepening AWS Integrations

The past 12 months of collaboration with AWS were shaped around one theme:

Make Tiger Cloud feel native inside AWS architectures.

We approached this holistically spanning secure connectivity, observability, billing, ingest and finally lakehouse interoperability.

Fast Ingest

Ingest has been one of the biggest areas of investment this year. Across different industries, AWS customers generate time-series data in many ways: IoT fleets send telemetry through IoT Core or drop device exports into S3, financial firms stream market data through Kafka or Amazon MSK, and application teams accumulate large volumes of event or log data that regularly land in S3. These are different workloads and different customers, but they all shared the same pain: getting time-stamped data into Postgres required a patchwork of custom pipelines, consumers, and periodic backfills that were hard to scale and harder to maintain.

To simplify this, we spent the past year building native ingestion paths for Kafka / Amazon MSK, RDS for PostgreSQL, and Aurora PostgreSQL—all currently in beta — so that streams and operational data can flow directly into Tiger Cloud without bespoke glue code.

With our Postgres source connectors, customers can replicate existing time-series tables from RDS or Aurora into Tiger Cloud, where they’re converted into optimized hypertables for high-ingest workloads and fast queries, all without modifying their application or schema.

S3 Connector Is Now Generally Available

Alongside these efforts, we also introduced a new S3 Connector, which has quickly become one of the most common ingest paths for AWS users. And today, we’re announcing its general availability. It continuously loads Parquet and CSV files from S3 into hypertables, handles late-arriving files, and makes historical data immediately available for real-time analytics without the Glue jobs, Lambdas, or custom ingestion services teams used to build.

Taken together, these capabilities create a cleaner, more AWS-native ingest model: whether your time-series data originates from IoT devices, market data feeds, event systems, or existing Postgres deployments, it can now flow directly into Tiger Cloud without additional code or operational overhead.

Lakehouse Interoperability

For many AWS customers, Amazon S3 serves as the foundation of their analytics and AI platforms, the place where governed, long-term datasets live and where engines like Athena, EMR or SageMaker expect to read data. Earlier this year, we introduced Tiger Lake in private beta, our Apache Iceberg integration, to make it easy for teams to expose curated operational and time-series data from Tiger Cloud directly into their S3-based lakehouse.

Tiger Lake works by using Postgres change data capture (CDC) to track every insert, update, and delete in source tables or hypertables. It then converts those changes into Iceberg-compliant commits and writes them to Amazon S3 via the S3 Tables interface. Because the output is a native Iceberg table stored in S3, AWS analytics and AI services can immediately query or train on the data using their existing tooling without batch exports, Spark pipelines, or glue code required. Operational changes in Tiger Cloud flow directly into the lakehouse as versioned Iceberg snapshots.

Tiger Lake Is Now Public Beta

Today we’re announcing that Tiger Lake is available in open beta, enabling any table or hypertable in Tiger Cloud to be continuously published as an Iceberg table on S3.

Tiger Cloud powers the real-time, high-ingest workloads that vanilla Postgres struggles with, while your AWS analytics and AI stack reads the same data through Iceberg on S3. It’s a natural bridge between operational Postgres workflows and the lakehouse architectures that drive analytics, ML, and enterprise intelligence on AWS.

Secure Connectivity

Customers want their databases to plug into AWS environments in the same way they already connect to RDS, Aurora, or Redshift to ensure their data and applications remain secure. Tiger Cloud has supported VPC peering for years,  making private, single-VPC deployments straightforward. At the beginning of this year, our new Transit Gateway support expanded that pattern to multi-account, multi-VPC organizations. Today, customers can connect Tiger Cloud using well-understood AWS constructs, without VPNs, proxies, or public endpoints.

Observability

Observability has been AWS-native in Tiger Cloud for a long time. Tiger Cloud integrates directly with Amazon CloudWatch for both metrics and logs, so teams can monitor their database using the same tooling they rely on for EC2, EKS, Lambda, MSK, and the rest of their AWS environment.

Tiger Cloud streams operational metrics into CloudWatch Metrics and sends structured logs to CloudWatch Logs, making it easy to build dashboards, set alarms, and satisfy compliance requirements without new tooling. 

Billing

Finally, we wanted the commercial experience to feel as seamless as the technical one. Tiger Cloud is fully integrated into AWS Marketplace, allowing customers to use the same procurement paths they already use for other AWS services.

For teams that want to get started quickly, Tiger Cloud supports pay-as-you-go billing directly through their AWS account. There’s no new vendor onboarding or separate invoice; usage simply appears on the existing monthly AWS bill.

For larger organizations with specific architectural, security, or cost requirements, we also support private offers, giving enterprises the ability to secure annual commitments, customized pricing, and tailored deployment guidance, all handled through AWS Marketplace.

Case Study: Speedcast’s Unified Architecture on AWS

Speedcast runs a global telecom network for remote industries, combining satellite and terrestrial links to keep ships, rigs, and NGOs online.

Previously, Speedcast had to juggle separate geospatial, relational, and time-series stores plus aging SCADA systems, stitching them together with fragile ETL pipelines that slowed insights and raised operational risk. With Tiger Lake in their AWS + Tiger Data stack, Speedcast dropped custom scripts and batching, using native integrations between their data lakehouse and Tiger Cloud to move toward a continuous data integration pipeline with Tiger Cloud at the center.

With Tiger Cloud as the “spider at the center of the web,” operations, data scientists, and customers now have a single, authoritative data source instead of hunting for data across systems. Platforms, dashboards and events are powered by the same database in real-time, regardless of workload pattern, with every system able to communicate with Apache Iceberg.

 "We stitched together Kafka, Flink, and custom code to stream data from Postgres to Iceberg. It worked, but it was fragile and high-maintenance,” said Kevin Otten, Director of Technical Architecture at Speedcast. “Tiger Lake replaces all of that with native infrastructure. It’s the architecture we wish we had from day one."

As Speedcast plans for service expansions and continues installing beyond 12,000 Starlink Terminals globally, Tiger Lake’s ingest pipeline will scale with them. For example, Speedcast can monitor usage patterns and spot emerging service-area outages in real-time before customers feel the impact. When a new service ticket is generated, Speedcast can drill into location, usage, and history with a single SQL query instead of bouncing between silos, reducing the time to resolution. 

Read the full case study in our blog.

Bringing Your Data Workloads Together on AWS

Modern applications shouldn’t require four different databases, half a dozen pipelines, and constant backfills just to keep data consistent. With Tiger Cloud and AWS, you get a unified Postgres engine that handles real-time ingest, high-performance time-series, vector search, and lakehouse integration—all inside the AWS architecture you already trust.

This is the future we’re building with AWS: simpler stacks, fewer moving parts, and one Postgres data layer for operational, analytical, and agentic workloads.

You can get started in minutes through the AWS Marketplace or sign up directly at tigerdata.com for free. We can’t wait to see what you build.

At Timescale, we see many devs looking for an alternative to AWS RDS for PostgreSQL. Drawn by performance and a transparent pricing model (no one has the time to understand RDS pricing), they often land at Timescale. When trying to help them, we couldn’t help but notice how lengthy and complex it is to migrate from RDS.

But what if you had a playbook to assist you along the way? If you’re embarking on a journey through uncharted territory, having a map makes all the difference. That’s what this blog post is: a step-by-step overview of the migration process from RDS to Timescale using live migrations. This migration workflow ensures a smooth transition (even for heavy workloads) while helping you avoid common pitfalls and harness our features. Think of it as your GPS for database migration.

Steps for a Successful Database Migration

Migrating a database is a complex process due to all the moving parts you’ll need to handle to ensure a seamless and safe transition of your data. A successful database migration typically involves several steps:

• Assessment: understand your current database's size, complexity, and dependencies.
• Planning: decide on a migration strategy, schedule downtime if necessary, and prepare a backup plan in case something goes wrong.
• Enable hypertables: to leverage Timescale’s performance optimization, compression, continuous aggregates, and data tiering, you have to enable hypertables on your time-series tables. 
• Data migration: move the old data and incoming data during migration from the old database to the new one with minimal downtime.
• Testing: rigorously test the new database with your applications to ensure everything works as expected.
• Cutover: finally, switch over from the old database to the new one, which usually involves a period of downtime. (If you follow our playbook, we ensure minimal downtime.)

Our playbook covers all the bases for a successful migration and streamlines it, allowing you to skip some of these steps. For example, we devised a way for you to enable one of Timescale’s most popular features, hypertables, in your target database while migrating your data. This means that all the data coming into your target database will be automatically partitioned when it comes into Timescale, saving you precious time.

This helpful aid is already part of our live migrations solution, a database migration workflow for Timescale based on pg_dump/pg_restore (for schema) and PostgreSQL logical decoding (for live data). But now, we have accelerated the process even more, shortening the number of steps and making it even more straightforward. Let’s jump into it.

Steps for Migrating From AWS RDS to Timescale

For a detailed step-by-step guide to migrate your database(s) from Amazon RDS for PostgreSQL to Timescale, we recommend you read our documentation. However, here is a high-level overview of the process. You’ll have to follow these steps:

1. Create a Timescale instance

Sign up or log in to Timescale Cloud and click on "Create service." Choose a Time-series service with your desired CPU and Memory plan. We recommend a minimum of 4 CPUs and 8 GB memory for migration. Click on "Download the cheatsheet" post-service creation to obtain an SQL file that contains the login details for your new service. Alternatively, you can copy the details directly from this page. After copying your password, click "I stored my password, go to service overview" at the bottom of the page. Once your service is ready to use, it will be labeled as "Running" in the Service Overview, displayed in green.

2. Collect information from your AWS RDS instance

The AWS RDS management console is extensive, containing numerous details. Our customers often express that locating requirement details and taking actions in AWS is time-consuming, requiring manual navigation of various screens and documentation to find the relevant information. Additionally, AWS has its own intricacies, such as parameter groups, which require engineers to invest effort in understanding the concepts and gathering the required information.

To prepare an AWS RDS instance for migration, you need the following information about the instance as the first step:

1. Endpoint
2. Port
3. Master username
4. Master password
5. VPC
6. DB instance parameter group

3. Update the following parameters of the AWS RDS for PostgreSQL instance

The live migration offered by Timescale is powered by logical decoding, which consumes Write-Ahead Logs (WAL) to synchronize real-time changes happening on the source database during the migration. Therefore, you need to set the wal_level to logical. 

Additionally, you must set old_snapshot_threshold to -1 to preserve the snapshots until the migration is complete. Not setting this parameter to -1 can cause errors in the logical decoding process, as the database performs periodic maintenance checks. You need to update the following configurations:

1. wal_level: set to logical
2. old_snapshot_threshold: set to -1

4. Prepare the intermediate machine to start the migration process

To migrate a database from a source to a target, an intermediate machine is necessary. This machine is responsible for pulling data from the source database and pushing it to the target database. Specific migration tools are required to perform actions on both the source and target databases to complete the migration. The intermediate machine will host these migration tools throughout the entire migration process.

The recommended steps are the following:

1. Set up an EC2 instance in the same region as your source and target databases.
2. Configure your EC2 instance to connect to your AWS RDS instance. This involves updating the security group of your RDS instance to allow the connection from the EC2 instance.

5. Perform the database migration

Now that the source database (AWS RDS instance) is ready for migration, an intermediate machine is prepared to execute the migration, and the target database (your Timescale instance) is up and running, we can proceed with the actual migration process.

1. Set source database uri (i.e., AWS RDS instance) and target database uri (i.e., Timescale instance).

export TARGET=<target_db_uri>

export SOURCE=<source_db_uri> 

2. Execute the following command to initiate the migration. We have packaged all the necessary tools for live migration in the docker image. Simply run the command below and wait for the migration to complete.

docker run --rm -dit --name live-migration \
  -e PGCOPYDB_SOURCE_PGURI=$SOURCE \
  -e PGCOPYDB_TARGET_PGURI=$TARGET \
  -v ~/live-migration:/opt/timescale/ts_cdc \
  timescale/live-migration:v0.0.1

During this step, the live migration workflow will copy existing data from the source database to the target database, as well as replicate ongoing changes (change data capture) from the source to the target. The copying process will occur sequentially, beginning with the existing data and then applying ongoing changes. The output logs of this step will display the migration progress and provide prompts to verify the target database before transitioning applications to use the target database as the primary.

3. Verify the data consistency between the source and target databases once the live migration is synchronized. Once you are confident that the data consistency checks have been successful, proceed with the application switchover to the target database by promoting it as the primary database.

And you’re set! Welcome to Timescale!

Why Choose Timescale Over RDS

If you’re reading this article because you’re contemplating a migration from RDS to Timescale, know that moving your data will not only be easy but will also come with the following benefits:

44 % faster data ingestion 

During our 16-thread ingestion benchmark, where we inserted nearly one billion rows of data, we observed impressive results when running Timescale and RDS. Timescale outperformed RDS by 32 % with 4 vCPUs and by 44 % with 8 vCPUs. Both systems had the same I/O performance configured on their gp3 disk.

Up to 350x faster queries

Query performance optimization is crucial in a time-series database, especially when powering real-time dashboards. The Time-Series Benchmarking Suite (TSBS), which we use to run our benchmarks, includes a variety of queries, each with its complex description. For the RDS benchmark, we conducted 100 runs of each query on 4 vCPU instance types and recorded the results.

The table demonstrates that Timescale outperforms Amazon RDS consistently, often by more than 100x. In some cases, Timescale performs over 350x better without any degradation for any query type. The table below displays the data for 4 vCPU instances, but similar results were observed across all CPU types tested. With a high instance workload, you can achieve even better results.

95% storage savings

In our benchmark, all data, except for the most recent partition, is compressed into our native columnar format. This format utilizes advanced algorithms to reduce the required storage space for the CPU table significantly. Despite compression, you can still access the data as usual, but with the added advantages of a smaller size and a columnar structure.

Reducing storage usage can result in smaller volumes, lower costs, and faster access. We achieved a 95 % reduction, from 159 GB to 8.6 GB—these numbers are not uncommon for real customer workloads.

And even more features

Check out the Timescale vs. Amazon RDS PostgreSQL benchmark blog post for more details.

Next Steps

If you’re considering migrating from AWS RDS but still want to keep the PostgreSQL you know and love, this playbook provides a good overview of how quickly and easily it is to migrate to Timescale using the live migrations solution. We hope it will help you achieve your desired destination—a high-performance PostgreSQL but faster database with predictable, unambiguous billing. If you’re still on the fence, create a free Timescale account and try it out for 30 days.

We will continue to iterate on our migration strategies—we have more aside from live migrations, targeted at different needs and use cases—to ensure that moving to Timescale is just as easy as using our cloud database platform. Read our documentation for more details:

• Live migrations from AWS RDS for PostgreSQL to Timescale
• Pg_dump/pg_restore from AWS RDS for PostgreSQL to Timescale
• Live migrations for any PostgreSQL to Timescale