A municipal rose-garden inventory already lives in a PostgreSQL-compatible database, and the team wants embeddings next to those rows. Which option should they pick rather than inventing a new search product by default?
Select an answer to reveal the explanation.
Short Explanation
Think of embeddings sitting next to the rose-garden rows you already keep in PostgreSQL. Aurora or RDS for PostgreSQL. A blog-named extra product, Transcribe, or a kiosk spreadsheet is not that default.
Full Explanation
When the rose-garden inventory already lives in a PostgreSQL-compatible engine, the default path is to keep embeddings beside those rows in Amazon Aurora or Amazon RDS for PostgreSQL rather than inventing a separate search product. PostgreSQL extensions commonly used for vectors (for example pgvector) let the team store embedding columns next to plant IDs, bed locations, and care notes, then filter and join with ordinary SQL. That preserves transactional consistency, existing backups, and staff SQL skills while adding similarity search where the data already lives.
Choosing a brand-new search product only because a blog named it adds operational surface area without proving the current PostgreSQL estate cannot meet the need. Amazon Transcribe converts speech to text; it does not store table rows or host vector columns for an inventory. A kiosk spreadsheet cannot enforce schema, concurrency, or reliable nearest-neighbor search beside authoritative garden records.
Exam caveat: 'use what you already operate' applies when the existing store is in-scope and capable; if latency, scale, or hybrid lexical search outgrow Postgres, a dedicated search service can still be justified—but that is an evidence-based escalation, not a blog-driven default.
Operational check: measure embedding dimension and row count, enable the vector extension on a non-production Aurora/RDS clone, index a sample of rose rows, and confirm filtered similarity queries return expected cultivars before changing the production schema.