4 posts tagged with "performance"

Babelfish translates T-SQL to PostgreSQL internally. For most index operations and query tuning work, this is transparent: you write the same CREATE INDEX syntax you would use on SQL Server, and Babelfish creates the corresponding PostgreSQL index. Some SQL Server performance tooling does not map cleanly to the PostgreSQL layer, and it is useful to know where the boundaries are before you start profiling.

This post documents index behaviour and query performance tooling in Babelfish 4.8.0, based on confirmed results from live testing on a FoundryDB staging instance. All results use a 10,000-row table tested against PostgreSQL 16.11.

Getting good write throughput from OpenSearch requires understanding three things: the refresh cycle, translog durability, and shard sizing. This post benchmarks bulk indexing with default and tuned settings on a live OpenSearch 2.19.1 cluster managed by FoundryDB. The cluster is a single-node tier-2 (2 CPU, 4 GB RAM), which is the smallest configuration available. Numbers from larger nodes will be better, but the ratios between default and tuned settings hold.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

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.

Reactive autoscaling has a fundamental problem: it waits for something to go wrong. Your database hits 95% CPU, the autoscaler wakes up, requests a resize, and for the next few minutes your application eats latency while the new resources come online. If your traffic is predictable (and most production traffic is), this delay is avoidable.

FoundryDB's predictive autoscaling engine learns your workload's seasonal patterns and scales your database before demand spikes arrive. It combines real-time metric thresholds with historical baselines, anomaly detection, and configurable cost limits so you stay fast without overspending.