MONOPOLY — Technology Decision Matrix
When to Use
- Use this skill when the task matches this description: Reference document for monopoly tech-matrix.
Table of Contents
- Database Selection
- Cache Selection
- Message Queue / Event Streaming
- API Protocol
- Search Engine
- Object Storage
- Container Orchestration
- Load Balancer
- Observability Stack
- CDN
1. Database Selection
Relational (SQL)
| Database |
Best For |
Avoid When |
Scale Ceiling |
| PostgreSQL |
Complex queries, JSONB, GIS, strong consistency, most default use cases |
Ultra-high write throughput (>100K writes/s) |
~10TB single node; use Citus for horizontal |
| MySQL / MariaDB |
Read-heavy apps, legacy systems, WordPress/Drupal ecosystem |
Complex queries, full ACID at scale |
~10TB; use Vitess for sharding |
| CockroachDB |
Global distributed SQL, geo-partitioning, multi-region |
Simple single-region apps (overkill) |
Petabyte-scale |
| PlanetScale |
MySQL-compatible, serverless, branch-based workflow |
Complex JOINs (foreign keys removed by design) |
Very high — Vitess based |
| Amazon Aurora |
AWS-native apps, managed PostgreSQL/MySQL, high availability |
Non-AWS environments |
Up to 128TB, 15 replicas |
NoSQL
| Database |
Best For |
Avoid When |
Scale Ceiling |
| MongoDB |
Flexible schema, document model, prototyping |
Financial transactions requiring ACID |
Petabyte-scale with sharding |
| DynamoDB |
Key-value at massive scale, AWS-native, serverless, predictable latency |
Complex queries, ad-hoc analytics, JOINs |
Unlimited (AWS-managed) |
| Cassandra |
Write-heavy, time-series, wide-column, geographically distributed |
Read-heavy with complex queries |
Petabyte-scale; used at Apple, Netflix |
| Redis |
Cache, sessions, leaderboards, pub/sub, rate limiting |
Primary data store for complex models |
~1TB per node; cluster for more |
| Elasticsearch |
Full-text search, log aggregation, analytics |
Primary database (durability risk) |
Petabyte-scale with clusters |
| InfluxDB |
Time-series metrics, IoT, monitoring data |
General-purpose data |
Very high write throughput |
| Neo4j |
Graph data, social networks, recommendation engines, fraud detection |
Non-graph data (overhead not worth it) |
Billions of nodes |
Decision Framework
Is your data relational (joins, foreign keys, transactions)?
YES → Start with PostgreSQL
NO → Continue below
Is your primary access pattern key-value?
YES, need extreme scale → DynamoDB or Cassandra
YES, need speed/cache → Redis
Is your data document-shaped (nested, flexible schema)?
YES → MongoDB
Is it time-series (metrics, logs, IoT)?
YES → InfluxDB or TimescaleDB
Is it graph (relationships are the data)?
YES → Neo4j
Is it search?
YES → Elasticsearch / OpenSearch
2. Cache Selection
| Technology |
Best For |
Max Single Node |
Cluster Support |
| Redis |
Sessions, leaderboards, pub/sub, complex data structures, Lua scripting |
~1TB RAM |
Yes (Redis Cluster, Redis Sentinel) |
| Memcached |
Simple key-value, multi-threaded, large object cache |
~64GB RAM |
Yes (client-side sharding) |
| Varnish |
HTTP reverse proxy cache, full-page caching |
RAM bound |
Limited |
| CloudFront / CDN |
Static assets, edge caching globally |
N/A (distributed) |
Built-in global distribution |
Default recommendation: Redis — more features, better ecosystem, active development.
Use Memcached only when: you need multi-threading for CPU-bound caching workloads and don't need data structures beyond string.
3. Message Queue / Event Streaming
| Technology |
Model |
Best For |
Throughput |
Retention |
| Apache Kafka |
Log-based streaming |
Event sourcing, high-throughput pipelines, replay, audit |
Millions msg/s |
Days to forever |
| RabbitMQ |
AMQP message broker |
Task queues, RPC, routing, fanout |
50K–100K msg/s |
Until consumed |
| AWS SQS |
Managed queue |
AWS-native, simple task queue, serverless |
Very high (managed) |
Up to 14 days |
| AWS SNS |
Pub/sub notification |
Fan-out to many subscribers (email, SMS, Lambda, SQS) |
Very high (managed) |
No retention |
| Google Pub/Sub |
Managed streaming |
GCP-native, global, serverless |
Very high (managed) |
Up to 7 days |
| Redis Pub/Sub |
In-memory pub/sub |
Real-time notifications, low latency, fire-and-forget |
Very high |
None (no retention) |
| NATS |
Lightweight messaging |
IoT, microservices, low latency |
Very high |
JetStream adds retention |
Decision Matrix
Need event replay / audit trail?
YES → Kafka or Kinesis
Need simple task queue with retries and DLQ?
AWS shop → SQS
Self-hosted → RabbitMQ
Need real-time pub/sub with no persistence?
Redis Pub/Sub or NATS
Need fan-out to multiple consumers?
Kafka (consumer groups) or SNS → SQS fan-out
Need < 5 minutes guaranteed delivery, AWS-native, zero ops?
SQS
Volume > 1 million messages/second?
Kafka (self-hosted) or Kinesis (managed)
4. API Protocol
| Protocol |
Best For |
Avoid When |
| REST (HTTP/JSON) |
Public APIs, CRUD, browser clients, simplicity |
Strict typing required; high-performance internal services |
| GraphQL |
Complex client data requirements, mobile (reduce over-fetching), BFF pattern |
Simple CRUD; not worth the complexity |
| gRPC (HTTP/2 + Protobuf) |
Internal microservice communication, low latency, strict contracts, streaming |
Public browser APIs (needs gRPC-web) |
| WebSocket |
Real-time bidirectional (chat, live dashboards, multiplayer games) |
One-way server push (use SSE instead) |
| SSE (Server-Sent Events) |
Server → client push (notifications, live feeds) |
Bidirectional communication |
| GraphQL Subscriptions |
Real-time with GraphQL schema consistency |
Simple push scenarios |
Default recommendation:
- External / public: REST
- Internal service-to-service: gRPC
- Real-time features: WebSocket or SSE
5. Search Engine
| Technology |
Best For |
Avoid When |
| Elasticsearch |
Full-text search, log analytics (ELK), complex aggregations |
Simple lookups; operational overhead is high |
| OpenSearch |
AWS-native Elasticsearch alternative |
Non-AWS preferred setups |
| Typesense |
Simple, fast full-text search, typo tolerance, easy ops |
Complex aggregations at massive scale |
| Algolia |
Managed search-as-a-service, fast setup, great UI |
High volume (expensive); self-hosted preference |
| Meilisearch |
Self-hosted, developer-friendly, fast relevancy |
Enterprise-scale analytics |
| PostgreSQL FTS |
Basic full-text search, already using PostgreSQL |
High relevancy requirements or large datasets |
Rule of thumb: Use PostgreSQL FTS under 1M documents. Move to Typesense or Elasticsearch above that.
6. Object Storage
| Service |
Best For |
Egress Cost |
| AWS S3 |
AWS-native apps, de facto standard, massive ecosystem |
$0.09/GB (expensive) |
| Cloudflare R2 |
S3-compatible, zero egress cost, global |
$0.00 egress |
| GCS |
GCP-native |
$0.12/GB |
| Azure Blob |
Azure-native |
$0.087/GB |
| Backblaze B2 |
Cost-sensitive, S3-compatible |
Free with Cloudflare |
| MinIO |
Self-hosted S3-compatible |
Self-managed |
Cost optimization tip: Use Cloudflare R2 for user-facing media delivery (zero egress). Use S3 for internal/AWS-integrated storage.
7. Container Orchestration
| Technology |
Best For |
Avoid When |
| Kubernetes (K8s) |
Large teams, complex deployments, multi-cloud, full control |
Small teams (ops overhead is very high) |
| AWS ECS + Fargate |
AWS-native, serverless containers, simpler than K8s |
Multi-cloud or K8s ecosystem tools needed |
| AWS EKS |
Managed K8s on AWS, best of both |
Small teams; Fargate may be enough |
| GKE (Google) |
Best managed K8s, GCP-native, Autopilot mode |
Non-GCP environments |
| Docker Compose |
Local dev, small single-server deployments |
Production at any meaningful scale |
| Nomad |
HashiCorp ecosystem, simpler than K8s, multi-workload |
K8s ecosystem tools required |
Startup default: ECS + Fargate (zero cluster management).
Scale default: EKS or GKE once team > 5 engineers or services > 10.
8. Load Balancer
| Technology |
Layer |
Best For |
| AWS ALB |
L7 (HTTP/HTTPS) |
AWS apps, path-based routing, WebSocket, HTTP/2 |
| AWS NLB |
L4 (TCP/UDP) |
Ultra-low latency, static IP, non-HTTP protocols |
| GCP GLB |
L7 global |
GCP apps, global anycast, single IP worldwide |
| Nginx |
L4/L7 |
Self-hosted, reverse proxy, flexible config |
| HAProxy |
L4/L7 |
High performance self-hosted, advanced routing |
| Cloudflare |
L7 global + DDoS |
DDoS protection + CDN + load balancing combined |
| Traefik |
L7 |
Kubernetes-native, automatic SSL, service discovery |
9. Observability Stack
Metrics
| Tool |
Best For |
| Prometheus + Grafana |
Self-hosted, open-source, Kubernetes-native |
| Datadog |
Managed, APM + infra + logs unified, expensive |
| CloudWatch |
AWS-native, zero setup, integrated with AWS services |
| New Relic |
APM-focused, good for application-level insights |
Logging
| Tool |
Best For |
| ELK Stack (Elasticsearch + Logstash + Kibana) |
Self-hosted, powerful, high volume |
| Loki + Grafana |
Lightweight, Kubernetes-native, cheap |
| Splunk |
Enterprise, compliance, expensive |
| AWS CloudWatch Logs |
AWS-native, zero setup |
| Datadog Logs |
Unified with metrics, expensive |
Distributed Tracing
| Tool |
Best For |
| Jaeger |
Open-source, Kubernetes-native, OpenTelemetry |
| Zipkin |
Simple, lightweight, good integrations |
| AWS X-Ray |
AWS-native, integrates with Lambda, ECS |
| Datadog APM |
Managed, unified with metrics and logs |
| Honeycomb |
High-cardinality event-based observability |
Recommended open-source stack: Prometheus + Grafana + Loki + Jaeger (all integrate via OpenTelemetry)
Recommended managed stack: Datadog (expensive but unified) or Grafana Cloud
10. CDN
| Technology |
Best For |
Edge Locations |
| Cloudflare |
DDoS protection + CDN + DNS, best free tier, edge workers |
300+ |
| AWS CloudFront |
AWS-native, deep S3 and API GW integration |
450+ |
| Akamai |
Enterprise, highest performance, expensive |
4000+ |
| Fastly |
Real-time purging, streaming, VCL customization |
90+ |
| Vercel Edge / Netlify |
Jamstack, frontend-first, zero config |
100+ |
Default recommendation: Cloudflare for most use cases (best value, DDoS included, free SSL, Workers for edge compute).
Scale Benchmarks Quick Reference
| Technology |
Write Throughput |
Read Throughput |
Notes |
| PostgreSQL (single) |
~10K writes/s |
~50K reads/s |
With connection pooling |
| PostgreSQL (replicas) |
~10K writes/s |
~200K reads/s |
4 replicas |
| MySQL (single) |
~15K writes/s |
~60K reads/s |
|
| Cassandra |
~1M writes/s |
~500K reads/s |
10-node cluster |
| Redis |
~1M ops/s |
~1M ops/s |
Single node in-memory |
| Kafka |
~1M msgs/s |
~1M msgs/s |
Per partition |
| Elasticsearch |
~50K docs/s |
~10K queries/s |
Per node |
| MongoDB |
~50K writes/s |
~100K reads/s |
Per replica set |
All benchmarks are approximate and depend heavily on hardware, payload size, and query complexity.
Limitations
- This is a reference document and may not cover all edge cases. Always verify architectures before production.
Source: sickn33/agentic-awesome-skills → skills/monopoly/tech-matrix/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/monopoly/tech-matrix/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/monopoly/tech-matrix/SKILL.md
1---2name: tech-matrix3description: Reference document for monopoly tech-matrix.4---5
6
7# MONOPOLY — Technology Decision Matrix
8
9## When to Use
10- Use this skill when the task matches this description: Reference document for monopoly tech-matrix.
11
12## Table of Contents
131. Database Selection
142. Cache Selection
153. Message Queue / Event Streaming
164. API Protocol
175. Search Engine
186. Object Storage
197. Container Orchestration
208. Load Balancer
219. Observability Stack
2210. CDN
23
24---
25
26## 1. Database Selection
27
28### Relational (SQL)
29
30| Database | Best For | Avoid When | Scale Ceiling |
31|----------|----------|------------|---------------|
32| **PostgreSQL** | Complex queries, JSONB, GIS, strong consistency, most default use cases | Ultra-high write throughput (>100K writes/s) | ~10TB single node; use Citus for horizontal |
33| **MySQL / MariaDB** | Read-heavy apps, legacy systems, WordPress/Drupal ecosystem | Complex queries, full ACID at scale | ~10TB; use Vitess for sharding |
34| **CockroachDB** | Global distributed SQL, geo-partitioning, multi-region | Simple single-region apps (overkill) | Petabyte-scale |
35| **PlanetScale** | MySQL-compatible, serverless, branch-based workflow | Complex JOINs (foreign keys removed by design) | Very high — Vitess based |
36| **Amazon Aurora** | AWS-native apps, managed PostgreSQL/MySQL, high availability | Non-AWS environments | Up to 128TB, 15 replicas |
37
38### NoSQL
39
40| Database | Best For | Avoid When | Scale Ceiling |
41|----------|----------|------------|---------------|
42| **MongoDB** | Flexible schema, document model, prototyping | Financial transactions requiring ACID | Petabyte-scale with sharding |
43| **DynamoDB** | Key-value at massive scale, AWS-native, serverless, predictable latency | Complex queries, ad-hoc analytics, JOINs | Unlimited (AWS-managed) |
44| **Cassandra** | Write-heavy, time-series, wide-column, geographically distributed | Read-heavy with complex queries | Petabyte-scale; used at Apple, Netflix |
45| **Redis** | Cache, sessions, leaderboards, pub/sub, rate limiting | Primary data store for complex models | ~1TB per node; cluster for more |
46| **Elasticsearch** | Full-text search, log aggregation, analytics | Primary database (durability risk) | Petabyte-scale with clusters |
47| **InfluxDB** | Time-series metrics, IoT, monitoring data | General-purpose data | Very high write throughput |
48| **Neo4j** | Graph data, social networks, recommendation engines, fraud detection | Non-graph data (overhead not worth it) | Billions of nodes |
49
50### Decision Framework
51
52```
53Is your data relational (joins, foreign keys, transactions)?
54 YES → Start with PostgreSQL
55 NO → Continue below
56
57Is your primary access pattern key-value?
58 YES, need extreme scale → DynamoDB or Cassandra
59 YES, need speed/cache → Redis
60
61Is your data document-shaped (nested, flexible schema)?
62 YES → MongoDB
63
64Is it time-series (metrics, logs, IoT)?
65 YES → InfluxDB or TimescaleDB
66
67Is it graph (relationships are the data)?
68 YES → Neo4j
69
70Is it search?
71 YES → Elasticsearch / OpenSearch
72```
73
74---
75
76## 2. Cache Selection
77
78| Technology | Best For | Max Single Node | Cluster Support |
79|------------|----------|----------------|----------------|
80| **Redis** | Sessions, leaderboards, pub/sub, complex data structures, Lua scripting | ~1TB RAM | Yes (Redis Cluster, Redis Sentinel) |
81| **Memcached** | Simple key-value, multi-threaded, large object cache | ~64GB RAM | Yes (client-side sharding) |
82| **Varnish** | HTTP reverse proxy cache, full-page caching | RAM bound | Limited |
83| **CloudFront / CDN** | Static assets, edge caching globally | N/A (distributed) | Built-in global distribution |
84
85**Default recommendation: Redis** — more features, better ecosystem, active development.
86
87Use **Memcached** only when: you need multi-threading for CPU-bound caching workloads and don't need data structures beyond string.
88
89---
90
91## 3. Message Queue / Event Streaming
92
93| Technology | Model | Best For | Throughput | Retention |
94|------------|-------|----------|------------|-----------|
95| **Apache Kafka** | Log-based streaming | Event sourcing, high-throughput pipelines, replay, audit | Millions msg/s | Days to forever |
96| **RabbitMQ** | AMQP message broker | Task queues, RPC, routing, fanout | 50K–100K msg/s | Until consumed |
97| **AWS SQS** | Managed queue | AWS-native, simple task queue, serverless | Very high (managed) | Up to 14 days |
98| **AWS SNS** | Pub/sub notification | Fan-out to many subscribers (email, SMS, Lambda, SQS) | Very high (managed) | No retention |
99| **Google Pub/Sub** | Managed streaming | GCP-native, global, serverless | Very high (managed) | Up to 7 days |
100| **Redis Pub/Sub** | In-memory pub/sub | Real-time notifications, low latency, fire-and-forget | Very high | None (no retention) |
101| **NATS** | Lightweight messaging | IoT, microservices, low latency | Very high | JetStream adds retention |
102
103### Decision Matrix
104
105```
106Need event replay / audit trail?
107 YES → Kafka or Kinesis
108
109Need simple task queue with retries and DLQ?
110 AWS shop → SQS
111 Self-hosted → RabbitMQ
112
113Need real-time pub/sub with no persistence?
114 Redis Pub/Sub or NATS
115
116Need fan-out to multiple consumers?
117 Kafka (consumer groups) or SNS → SQS fan-out
118
119Need < 5 minutes guaranteed delivery, AWS-native, zero ops?
120 SQS
121
122Volume > 1 million messages/second?
123 Kafka (self-hosted) or Kinesis (managed)
124```
125
126---
127
128## 4. API Protocol
129
130| Protocol | Best For | Avoid When |
131|----------|----------|------------|
132| **REST (HTTP/JSON)** | Public APIs, CRUD, browser clients, simplicity | Strict typing required; high-performance internal services |
133| **GraphQL** | Complex client data requirements, mobile (reduce over-fetching), BFF pattern | Simple CRUD; not worth the complexity |
134| **gRPC (HTTP/2 + Protobuf)** | Internal microservice communication, low latency, strict contracts, streaming | Public browser APIs (needs gRPC-web) |
135| **WebSocket** | Real-time bidirectional (chat, live dashboards, multiplayer games) | One-way server push (use SSE instead) |
136| **SSE (Server-Sent Events)** | Server → client push (notifications, live feeds) | Bidirectional communication |
137| **GraphQL Subscriptions** | Real-time with GraphQL schema consistency | Simple push scenarios |
138
139**Default recommendation:**
140- External / public: **REST**
141- Internal service-to-service: **gRPC**
142- Real-time features: **WebSocket** or **SSE**
143
144---
145
146## 5. Search Engine
147
148| Technology | Best For | Avoid When |
149|------------|----------|------------|
150| **Elasticsearch** | Full-text search, log analytics (ELK), complex aggregations | Simple lookups; operational overhead is high |
151| **OpenSearch** | AWS-native Elasticsearch alternative | Non-AWS preferred setups |
152| **Typesense** | Simple, fast full-text search, typo tolerance, easy ops | Complex aggregations at massive scale |
153| **Algolia** | Managed search-as-a-service, fast setup, great UI | High volume (expensive); self-hosted preference |
154| **Meilisearch** | Self-hosted, developer-friendly, fast relevancy | Enterprise-scale analytics |
155| **PostgreSQL FTS** | Basic full-text search, already using PostgreSQL | High relevancy requirements or large datasets |
156
157**Rule of thumb:** Use PostgreSQL FTS under 1M documents. Move to Typesense or Elasticsearch above that.
158
159---
160
161## 6. Object Storage
162
163| Service | Best For | Egress Cost |
164|---------|----------|------------|
165| **AWS S3** | AWS-native apps, de facto standard, massive ecosystem | $0.09/GB (expensive) |
166| **Cloudflare R2** | S3-compatible, **zero egress cost**, global | $0.00 egress |
167| **GCS** | GCP-native | $0.12/GB |
168| **Azure Blob** | Azure-native | $0.087/GB |
169| **Backblaze B2** | Cost-sensitive, S3-compatible | Free with Cloudflare |
170| **MinIO** | Self-hosted S3-compatible | Self-managed |
171
172**Cost optimization tip:** Use **Cloudflare R2** for user-facing media delivery (zero egress). Use **S3** for internal/AWS-integrated storage.
173
174---
175
176## 7. Container Orchestration
177
178| Technology | Best For | Avoid When |
179|------------|----------|------------|
180| **Kubernetes (K8s)** | Large teams, complex deployments, multi-cloud, full control | Small teams (ops overhead is very high) |
181| **AWS ECS + Fargate** | AWS-native, serverless containers, simpler than K8s | Multi-cloud or K8s ecosystem tools needed |
182| **AWS EKS** | Managed K8s on AWS, best of both | Small teams; Fargate may be enough |
183| **GKE (Google)** | Best managed K8s, GCP-native, Autopilot mode | Non-GCP environments |
184| **Docker Compose** | Local dev, small single-server deployments | Production at any meaningful scale |
185| **Nomad** | HashiCorp ecosystem, simpler than K8s, multi-workload | K8s ecosystem tools required |
186
187**Startup default:** ECS + Fargate (zero cluster management).
188**Scale default:** EKS or GKE once team > 5 engineers or services > 10.
189
190---
191
192## 8. Load Balancer
193
194| Technology | Layer | Best For |
195|------------|-------|----------|
196| **AWS ALB** | L7 (HTTP/HTTPS) | AWS apps, path-based routing, WebSocket, HTTP/2 |
197| **AWS NLB** | L4 (TCP/UDP) | Ultra-low latency, static IP, non-HTTP protocols |
198| **GCP GLB** | L7 global | GCP apps, global anycast, single IP worldwide |
199| **Nginx** | L4/L7 | Self-hosted, reverse proxy, flexible config |
200| **HAProxy** | L4/L7 | High performance self-hosted, advanced routing |
201| **Cloudflare** | L7 global + DDoS | DDoS protection + CDN + load balancing combined |
202| **Traefik** | L7 | Kubernetes-native, automatic SSL, service discovery |
203
204---
205
206## 9. Observability Stack
207
208### Metrics
209| Tool | Best For |
210|------|----------|
211| **Prometheus + Grafana** | Self-hosted, open-source, Kubernetes-native |
212| **Datadog** | Managed, APM + infra + logs unified, expensive |
213| **CloudWatch** | AWS-native, zero setup, integrated with AWS services |
214| **New Relic** | APM-focused, good for application-level insights |
215
216### Logging
217| Tool | Best For |
218|------|----------|
219| **ELK Stack** (Elasticsearch + Logstash + Kibana) | Self-hosted, powerful, high volume |
220| **Loki + Grafana** | Lightweight, Kubernetes-native, cheap |
221| **Splunk** | Enterprise, compliance, expensive |
222| **AWS CloudWatch Logs** | AWS-native, zero setup |
223| **Datadog Logs** | Unified with metrics, expensive |
224
225### Distributed Tracing
226| Tool | Best For |
227|------|----------|
228| **Jaeger** | Open-source, Kubernetes-native, OpenTelemetry |
229| **Zipkin** | Simple, lightweight, good integrations |
230| **AWS X-Ray** | AWS-native, integrates with Lambda, ECS |
231| **Datadog APM** | Managed, unified with metrics and logs |
232| **Honeycomb** | High-cardinality event-based observability |
233
234**Recommended open-source stack:** Prometheus + Grafana + Loki + Jaeger (all integrate via OpenTelemetry)
235**Recommended managed stack:** Datadog (expensive but unified) or Grafana Cloud
236
237---
238
239## 10. CDN
240
241| Technology | Best For | Edge Locations |
242|------------|----------|----------------|
243| **Cloudflare** | DDoS protection + CDN + DNS, best free tier, edge workers | 300+ |
244| **AWS CloudFront** | AWS-native, deep S3 and API GW integration | 450+ |
245| **Akamai** | Enterprise, highest performance, expensive | 4000+ |
246| **Fastly** | Real-time purging, streaming, VCL customization | 90+ |
247| **Vercel Edge / Netlify** | Jamstack, frontend-first, zero config | 100+ |
248
249**Default recommendation:** Cloudflare for most use cases (best value, DDoS included, free SSL, Workers for edge compute).
250
251---
252
253## Scale Benchmarks Quick Reference
254
255| Technology | Write Throughput | Read Throughput | Notes |
256|------------|-----------------|----------------|-------|
257| PostgreSQL (single) | ~10K writes/s | ~50K reads/s | With connection pooling |
258| PostgreSQL (replicas) | ~10K writes/s | ~200K reads/s | 4 replicas |
259| MySQL (single) | ~15K writes/s | ~60K reads/s | |
260| Cassandra | ~1M writes/s | ~500K reads/s | 10-node cluster |
261| Redis | ~1M ops/s | ~1M ops/s | Single node in-memory |
262| Kafka | ~1M msgs/s | ~1M msgs/s | Per partition |
263| Elasticsearch | ~50K docs/s | ~10K queries/s | Per node |
264| MongoDB | ~50K writes/s | ~100K reads/s | Per replica set |
265
266*All benchmarks are approximate and depend heavily on hardware, payload size, and query complexity.*
267
268
269## Limitations
270- This is a reference document and may not cover all edge cases. Always verify architectures before production.
271
272---
273
274**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/monopoly/tech-matrix/SKILL.md`
275
276**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/monopoly/tech-matrix/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/monopoly/tech-matrix/SKILL.md`
thedixitjain