16 posts tagged with "tutorial"

With your OpenSearch cluster running on FoundryDB, the next step is putting data into it and querying it. This post covers explicit index mappings, the bulk ingestion API, full-text search with relevance scoring, fuzzy matching, bool queries, and aggregations.

All results are from real queries run against OpenSearch 2.19.1 on FoundryDB staging. Replace YOUR_HOST and YOUR_DB_PASSWORD with your cluster values throughout.

Most database dashboards give you a SQL editor and wish you luck. That works fine when you remember the exact name of the pg_stat_user_tables view or the difference between information_schema.TABLES in MySQL versus PostgreSQL. For everyone else, there is the AI Query Console.

FoundryDB's AI Query Console lets you type a question in plain English, translates it to a database-native SQL query using Claude, and executes it against your running service. The entire flow is read-only by design. You cannot accidentally drop a table by asking a question.

SQL Server licensing costs add up fast. Per-core pricing, Software Assurance renewals, and the looming end of extended support for older versions push teams to look for alternatives. PostgreSQL is the obvious destination, but rewriting thousands of stored procedures, converting T-SQL syntax, and updating every connection string is a project nobody wants to start.

Babelfish for PostgreSQL changes the equation. It adds a SQL Server wire-protocol layer (TDS) on top of PostgreSQL, so your existing applications connect to port 1433 and run T-SQL queries as before. No driver changes. No syntax rewrites. On FoundryDB, you get a fully managed Babelfish instance running on PostgreSQL 16 with backups, TLS, monitoring, and point-in-time recovery built in.

Every managed database service on FoundryDB gets automated backups from the moment it starts running. There is nothing to configure, no S3 bucket to provision, and no cron job to maintain. Backups run daily, are encrypted before they leave the server, and are stored in object storage across a separate availability zone.

But automated daily backups are only half the story. For PostgreSQL, MySQL, and MongoDB, FoundryDB continuously archives write-ahead logs (WAL), binary logs (binlog), or oplogs to enable point-in-time recovery (PITR). This means you can restore to any specific second within a 7-day window, not just to the last daily snapshot.

This post covers how backups work across all engines, how to trigger and restore them, and how to use PITR to recover from the kind of mistakes that daily snapshots cannot fix.

Database upgrades are the kind of task that sounds simple until you remember what is at stake. A botched upgrade means downtime, and downtime means lost revenue, broken trust, and on-call engineers reading logs at 3 AM. Rolling updates help, but they still mutate your live environment in place. Blue-green deployments take a fundamentally different approach: build the new environment first, verify it works, then switch traffic over in one atomic step.

FoundryDB supports blue-green deployments as a first-class maintenance operation. You can validate prerequisites, provision a parallel green environment, let replication sync the data, and switchover when you are confident. If something goes wrong before or after the switch, you roll back.

Retrieval-Augmented Generation (RAG) has become the standard approach for grounding LLMs in factual, up-to-date data. Instead of fine-tuning a model on your corpus (expensive, slow, stale within weeks), you retrieve relevant context at query time and feed it to the LLM alongside the user's question.

In 2026, RAG is no longer experimental. It powers customer support bots, internal knowledge search, legal document analysis, and code assistants at thousands of companies. The architecture has stabilized around a common pattern: ingest documents, generate embeddings, store vectors, retrieve at query time. What varies is how well you operate the infrastructure underneath.

This post walks through building a production RAG pipeline on FoundryDB using PostgreSQL with pgvector, Kafka for document ingestion, and Valkey for result caching.

Every database connection costs memory. PostgreSQL forks a backend process per connection (roughly 5-10 MB each), and MySQL allocates per-thread buffers that scale with your buffer configuration. At 200 concurrent connections, the overhead is manageable. At 2,000, you are spending gigabytes of RAM on connection state instead of query execution.

Connection pooling sits between your application and the database, multiplexing many client connections over a small number of backend connections. FoundryDB provides PgBouncer for PostgreSQL and ProxySQL for MySQL, both managed through the API with no manual SSH or config file editing required.

Testing against realistic data is the difference between catching bugs before production and catching them in production. But getting a faithful copy of your production database into a staging environment usually means writing export scripts, waiting for dumps to transfer, provisioning infrastructure, and importing the data. For a 100 GB PostgreSQL database, that process can take hours and requires someone to babysit it.

FoundryDB's fork endpoint eliminates this entire workflow. One API call creates a fully independent copy of your database, running on its own VM with its own credentials, restored from a backup of the source service. The source database is never touched. The fork is provisioned, restored, and ready for connections in minutes.

Every RAG system needs the same boring middle layer: watch a table for changes, call an embedding API, write vectors back, handle retries, manage batches, build indexes, schedule cron jobs, and pray nothing drifts out of sync at 3 AM. FoundryDB's managed embedding pipelines eliminate that entire layer. You configure a pipeline, and your PostgreSQL data gets auto-vectorized with an HNSW index, ready for similarity search.

No ETL scripts. No cron jobs. No model orchestration code.

Event-driven architecture has moved from buzzword to baseline. If you are building microservices, real-time analytics, or data pipelines in 2026, Kafka is likely somewhere in the stack. The challenge is not whether to use it, but how to operate it without drowning in ZooKeeper configs, TLS certificate rotation, and broker rebalancing.

This post covers practical streaming patterns on FoundryDB's managed Kafka: topic design, partitioning strategies, consumer groups, schema enforcement, and monitoring. All examples use FoundryDB's Kafka 4.0 with KRaft mode and SASL/SCRAM authentication.