I'm planning to use RDS for PostgreSQL as the source of truth and OpenSearch Serverless NextGen for search. I'm deciding between using an OpenSearch Ingestion pipeline to synchronize the two systems or writing to both from my application API.
As I understand it, OpenSearch Ingestion OCUs and OpenSearch Serverless OCUs are billed separately, with no shared capacity. Ingestion appears to require at least one OCU and does not scale to zero, while the newer Serverless model can scale indexing and search capacity independently and reduce them after roughly 10 minutes of inactivity.
What I'm unsure about is whether an idle ingestion pipeline keeps the Serverless indexing capacity active. If the source database has no changes and the pipeline sends no bulk requests, I would expect the collection to become idle. However, I don't know whether the pipeline sends heartbeats, health checks, index checks, or other background requests that reset the inactivity timer.
Can anyone confirm how this behaves in practice and whether the pipeline's minimum OCU cost is separate from any Serverless charges?
3 Answers
The collection and ingestion capacity are separate billing meters, so you should assume you’ll pay the ingestion minimum in addition to any Serverless usage. A continuously running pipeline is not equivalent to an on-demand job and won’t disappear just because the source database is quiet.
There is some uncertainty around exactly which background requests a pipeline makes. In practice, pipelines may maintain connections or perform periodic health activity, and some users have observed target traffic that can keep a collection warm. I would not rely on the 10-minute scale-down behavior while the pipeline is running without confirming it through CloudWatch metrics and a controlled idle test.
Your billing interpretation is generally right: OpenSearch Ingestion is a separate managed service with its own OCU charges, and those OCUs do not pool with the Serverless collection. The ingestion pipeline also has a minimum capacity and does not scale to zero, so it remains an always-on cost even when there is little or no data to process.
For an occasional or low-volume synchronization job, writing to both systems from the application—or running a lightweight, retryable sync process—may be less expensive and simpler. An ingestion pipeline becomes more attractive when you need transformations, dead-letter handling, or multiple destinations.
Before adding another datastore, check whether PostgreSQL can cover the search requirements. Full-text search with tsvector and a GIN index handles many keyword-search workloads, while pg_trgm can help with fuzzy or typo-tolerant matching. Keeping PostgreSQL as the only source of truth avoids synchronization failures, extra operational complexity, and the fixed ingestion cost.
OpenSearch may still be justified for more advanced search, high scale, or specialized features, but for a small workload the API can often update both systems more cheaply if writes are idempotent and failures are retried carefully.
That makes sense. I’ll test an idle pipeline while watching the collection’s indexing capacity and request metrics rather than assuming that no source changes means no target activity.