ENTERPRISE_ASSESSMENT.md

TensorDB Enterprise Assessment Report

Date: March 5, 2026 Version Tested: v0.32 (commit d3cf7e1) Evaluator Role: DBA / Database Developer evaluating TensorDB as a potential replacement for Oracle, PostgreSQL, Redis, and SQLite in production workloads.

---

Executive Summary

Verdict: CONDITIONAL YES — Replace SQLite and Redis for specific embedded/analytical workloads. Do NOT replace Oracle or PostgreSQL for general-purpose OLTP production systems.

TensorDB is an impressive embedded bitemporal ledger database with a remarkably broad feature set for its maturity. It excels at point reads (263ns), single-row writes (2.6μs), temporal data management, and multi-model queries (SQL + full-text + vector + time-series). However, it has critical gaps that prevent it from replacing mature RDBMS systems in enterprise production: no multi-value INSERT, no subquery support in WHERE, no OFFSET, no cross-call transaction sessions, and no network-aware replication.

---

1. Benchmark Results (Measured)

All benchmarks run with Criterion 0.5 on the same machine, 100 samples each.

1.1 Point Read Latency

Engine	Latency	Throughput
TensorDB	263 ns	3.80 M reads/s
sled	261 ns	3.83 M reads/s
redb	582 ns	1.72 M reads/s
SQLite	1,118 ns	0.89 M reads/s

Analysis: TensorDB ties sled for fastest point reads — 4.2x faster than SQLite. The ShardReadHandle with parking_lot::RwLock delivers sub-300ns reads consistently. At 50K keys, TensorDB (298ns) even beats sled (327ns).

1.2 Point Write Latency

Engine	Latency	Writes/s
TensorDB (fast path)	2,602 ns	384K writes/s
sled	2,904 ns	344K writes/s
SQLite	43,895 ns	22.8K writes/s
redb	1,560,405 ns	641 writes/s

Analysis: TensorDB's lock-free FastWritePath delivers 16.8x faster writes than SQLite and 599x faster than redb. The channel-based write path (222μs) is slower but provides CDC guarantees.

1.3 Batch Write (100 rows)

Engine	Latency	Rows/s
SQLite	276 μs	362K rows/s
sled	621 μs	161K rows/s
TensorDB	1,610 μs	62K rows/s
redb	4,225 μs	23.7K rows/s

Analysis: TensorDB's batch writes are slower than SQLite because each write is individually timestamped for bitemporal semantics. This is a deliberate trade-off — every row gets its own commit_ts for MVCC. SQLite wins batch ingestion by 5.8x.

1.4 Prefix Scan (1000 keys)

Engine	Latency
redb	61 μs
SQLite	138 μs
sled	173 μs
TensorDB	247 μs

Analysis: TensorDB's prefix scan includes MVCC version filtering overhead. The 247μs for 1000 keys (4μs/key with version resolution) is acceptable for analytical queries.

1.5 SQL Query (SELECT 100 rows)

Operation	Latency
TensorDB SQL SELECT 100 rows	51.3 μs

No SQL comparison available for other embedded engines (sled/redb are KV-only). For context, 51μs for a parsed-planned-executed SQL query returning 100 rows is competitive with SQLite's prepared statement path.

1.6 Mixed Workload (80% read / 20% write)

Engine	Latency
sled	1.4 μs
SQLite	10.2 μs
TensorDB	17.3 μs
redb	301 μs

Analysis: Mixed workload is TensorDB's weakest relative benchmark. The write portion (20%) carries bitemporal overhead. Still 17x faster than redb and acceptable for most workloads.

1.7 CLI-Like End-to-End Bench

Operation	Latency
Full CLI-style workflow (create, insert, select, drop)	31.1 ms

This measures a complete real-world workflow including table creation, data insertion, querying, and cleanup.

---

2. Functional Test Results

2.1 Test Suite Summary

Metric	Result
Enterprise evaluation tests	50/50 passed
Full workspace test suite	800+ tests, 0 failures
Test suites	51 suites across 36+ files
Execution time (enterprise eval)	10.45 seconds
Execution time (full suite)	~45 seconds

2.2 Feature Parity Matrix

SQL Compliance

Feature	Oracle	PostgreSQL	SQLite	TensorDB	Status
CREATE/DROP TABLE	Yes	Yes	Yes	Yes	PASS
CREATE TABLE IF NOT EXISTS	Yes	Yes	Yes	No	FAIL
DROP TABLE IF EXISTS	Yes	Yes	Yes	No	FAIL
ALTER TABLE ADD COLUMN	Yes	Yes	Yes	Yes	PASS
ALTER TABLE DROP COLUMN	Yes	Yes	Yes	Yes	PASS
ALTER TABLE RENAME COLUMN	Yes	Yes	Yes	Yes	PASS
INSERT single row	Yes	Yes	Yes	Yes	PASS
INSERT multi-value	Yes	Yes	Yes	No	FAIL
INSERT ... RETURNING	Yes	Yes	No	Yes	PASS
UPDATE with WHERE	Yes	Yes	Yes	Yes	PASS
DELETE with WHERE	Yes	Yes	Yes	Yes	PASS
SELECT with projections	Yes	Yes	Yes	Yes	PASS
WHERE clause filtering	Yes	Yes	Yes	Yes	PASS
ORDER BY	Yes	Yes	Yes	Yes	PASS
LIMIT	Yes	Yes	Yes	Yes	PASS
OFFSET	Yes	Yes	Yes	No	FAIL
INNER JOIN	Yes	Yes	Yes	Yes	PASS
LEFT JOIN	Yes	Yes	Yes	Yes	PASS
RIGHT JOIN	Yes	Yes	Yes	Yes	PASS
CROSS JOIN	Yes	Yes	Yes	Yes	PASS
FULL OUTER JOIN	Yes	Yes	No	No	FAIL
Multi-table JOIN (3+)	Yes	Yes	Yes	Yes	PASS
Subqueries in SELECT	Yes	Yes	Yes	Yes	PASS
Subqueries in WHERE	Yes	Yes	Yes	No	FAIL
CTEs (WITH ... AS)	Yes	Yes	Yes	Yes	PASS
Window functions (ROW_NUMBER, RANK)	Yes	Yes	Yes	Yes	PASS
UNION / INTERSECT / EXCEPT	Yes	Yes	Yes	Yes	PASS
CASE expressions	Yes	Yes	Yes	Yes	PASS
GROUP BY / HAVING	Yes	Yes	Yes	Yes	PASS
Aggregate functions (COUNT, SUM, AVG, MIN, MAX)	Yes	Yes	Yes	Yes	PASS
LIKE / ILIKE	Yes	Yes	LIKE only	Yes	PASS
Prepared statements	Yes	Yes	Yes	Yes	PASS
Views (CREATE/DROP VIEW)	Yes	Yes	Yes	Yes	PASS
Indexes (CREATE/DROP INDEX)	Yes	Yes	Yes	Yes	PASS
Composite indexes	Yes	Yes	Yes	Yes	PASS
EXPLAIN / EXPLAIN ANALYZE	Yes	Yes	Yes	Yes	PASS
VACUUM	Yes	Yes	Yes	Yes	PASS
ANALYZE (table statistics)	Yes	Yes	Yes	Yes	PASS
SELECT without FROM	Yes	Yes	No	No	FAIL

SQL compliance score: 31/38 features (81.6%)

Data Types

Type	Oracle	PostgreSQL	SQLite	TensorDB
TEXT/VARCHAR	Yes	Yes	Yes	Yes
INTEGER (64-bit)	Yes	Yes	Yes	Yes
REAL/FLOAT	Yes	Yes	Yes	Yes
BOOLEAN	No (NUMBER)	Yes	No (int)	Yes
BLOB	Yes	Yes	Yes	Yes
DECIMAL	Yes	Yes	No	Yes
TIMESTAMP	Yes	Yes	No	Via INTEGER
JSON	No	Yes	No	Via TEXT
VECTOR	No	pgvector ext	No	Yes (native)
ARRAY	No	Yes	No	No
UUID	No	Yes	No	No

Transaction Support

Feature	Oracle	PostgreSQL	SQLite	TensorDB	Notes
BEGIN / COMMIT	Yes	Yes	Yes	Yes	Single sql() call only
ROLLBACK	Yes	Yes	Yes	Yes	Single sql() call only
SAVEPOINT / ROLLBACK TO	Yes	Yes	Yes	Yes
Nested transactions	Yes	Yes	No	Savepoints
Cross-connection transactions	Yes	Yes	No	No	Embedded-only
Snapshot isolation	Yes	Yes	WAL mode	Yes (MVCC)
Serializable isolation	Yes	Yes	Yes	No

Critical limitation: Transactions must be in a single db.sql("BEGIN; ...; COMMIT") call. There is no cross-call session state. This is a fundamental architectural constraint of the embedded API.

Advanced Features — Where TensorDB Excels

Feature	Oracle	PostgreSQL	SQLite	TensorDB
Bitemporal queries	Manual	temporal_tables ext	No	Native (AS OF, VALID AT)
System-time travel	Flashback	No	No	AS OF EPOCH N
Full-text search (BM25)	Oracle Text	tsvector	FTS5 ext	Native (MATCH, HIGHLIGHT)
Vector search (HNSW)	No	pgvector ext	No	Native (k-NN, <->)
Time-series	No	TimescaleDB ext	No	Native (TIME_BUCKET)
Event sourcing	No	No	No	Native
CDC (change data capture)	GoldenGate ($$$)	Logical replication	No	Native
Immutable ledger	No	No	No	Core architecture
GDPR erasure (FORGET KEY)	Manual	Manual	Manual	Native SQL command
Row-level security	VPD ($$$)	Yes	No	Yes (CREATE POLICY)
Audit log	Audit Vault ($$$)	pgAudit ext	No	Native
Structured error codes	Yes	Yes	Limited	Yes (T1xxx-T6xxx)
Plan guides	Yes	No	No	Yes (CREATE PLAN GUIDE)
Backup/Verify/Restore	RMAN	pg_dump	.backup	Native (VERIFY BACKUP)

---

3. Security Assessment

Security Feature	Status	Details
Authentication (CREATE USER / password)	PASS	bcrypt password hashing, session TTL
Role-based access control (RBAC)	PASS	admin/reader/writer roles, GRANT/REVOKE
Row-level security	PASS	CREATE POLICY ... USING (expr)
Audit logging	PASS	Immutable, tracks DDL/auth/security events
GDPR erasure	PASS	FORGET KEY erases all temporal versions
Encryption at rest	PARTIAL	AES-256-GCM behind feature flag, no key rotation
TLS/network encryption	N/A	Embedded library; pgwire server would need external TLS
SQL injection protection	PASS	Prepared statements with parameterized queries
Privilege escalation protection	PASS	Table-level privileges enforced

Security score: 8/9 applicable features

---

4. Operational Maturity Assessment

Capability	Status	Details
SHOW STATS	PASS	Query count, latency histogram, cache hit rate
SHOW SLOW QUERIES	PASS	Configurable threshold
SHOW ACTIVE QUERIES	PASS	Real-time query tracking
SHOW STORAGE	PASS	Per-shard storage breakdown
SHOW COMPACTION STATUS	PASS	L0-L6 level details
SHOW WAL STATUS	PASS	Per-shard WAL file sizes
SHOW AUDIT LOG	PASS	Security event history
EXPLAIN ANALYZE	PASS	Operation-level timing
Health endpoint	PASS	HTTP /health on pgwire port+1
Backup/Restore	PASS	Full + incremental, with VERIFY
VACUUM	PASS	Tombstone cleanup
Compaction scheduling	PASS	Time-window based
Per-query resource limits	PASS	QUERY_TIMEOUT, QUERY_MAX_MEMORY
Crash recovery	PASS	WAL replay, CRC-validated
Graceful multi-reopen	PASS	Tested 5 consecutive cycles

Operational maturity score: 15/15

---

5. Replacement Recommendations

5.1 Replace SQLite? YES, for specific workloads

Criterion	SQLite	TensorDB	Winner
Point read latency	1,118 ns	263 ns	TensorDB (4.2x)
Point write latency	43,895 ns	2,602 ns	TensorDB (16.8x)
Batch write (100)	276 μs	1,610 μs	SQLite (5.8x)
Prefix scan (1000)	138 μs	247 μs	SQLite (1.8x)
SQL completeness	Very high	High (81.6%)	SQLite
Temporal queries	None	Native	TensorDB
Full-text search	FTS5 extension	Native BM25	Tie
Vector search	None	Native HNSW	TensorDB
Ecosystem maturity	25+ years	New	SQLite
Data integrity	WAL	Bitemporal ledger	TensorDB

Recommendation: Replace SQLite with TensorDB when you need:

• Temporal/bitemporal data (audit trails, regulatory compliance, time travel)
• Multi-model queries (SQL + FTS + vector + time-series in one DB)
• High-throughput point reads/writes (3.8M reads/s, 384K writes/s)
• Immutable ledger semantics

Do NOT replace SQLite when you need:

• Maximum SQL standard compliance
• Batch ingestion performance
• Multi-value INSERT support
• Subqueries in WHERE clauses
• Broad ecosystem/tooling support

5.2 Replace Redis? YES, for persistence-required caching

Criterion	Redis	TensorDB
Point read latency	~100μs (network)	263 ns (embedded)
Point write latency	~100μs (network)	2,602 ns (embedded)
Data structures	Rich (lists, sets, sorted sets, streams)	KV + SQL + FTS + vectors
Persistence	RDB/AOF (optional)	Always durable (WAL + LSM)
TTL/Expiry	Native	Not native
Pub/Sub	Native	CDC (durable)
Clustering	Redis Cluster	Not yet (distributed crate WIP)
Memory management	In-memory first	Disk-first with caching
Temporal queries	None	Native

Recommendation: Replace Redis with TensorDB when you need:

• Durability-first with sub-microsecond reads (no network hop)
• SQL queryability on cached data
• Temporal versioning of cache entries
• Single embedded library instead of separate Redis server
• Audit trail on all data changes

Do NOT replace Redis when you need:

• Network-accessible shared cache across services
• Rich data structures (sorted sets, HyperLogLog, Streams)
• TTL-based automatic expiry
• Sub-millisecond network responses at massive scale
• Pub/Sub messaging patterns

5.3 Replace PostgreSQL? NO

Criterion	PostgreSQL	TensorDB
SQL completeness	~99%	81.6%
ACID (full isolation levels)	All 4	Snapshot only
Concurrent connections	Thousands	Embedded (in-process)
Replication	Streaming + logical	None (distributed WIP)
Extensions ecosystem	1000+	None
Stored procedures	PL/pgSQL, PL/Python, etc.	None
Foreign keys	Yes	No
Triggers	Yes	No
Materialized views	Yes	No
JSONB operations	Native	No
Partitioning	Native	Sharding (4 shards)
Point-in-time recovery	WAL archiving	Epoch-based
Connection pooling	pgBouncer, built-in	N/A
Production track record	30+ years	New

Why NOT: PostgreSQL is a battle-tested, full-featured RDBMS with complete SQL compliance, mature tooling, and decades of production hardening. TensorDB cannot match it for general-purpose OLTP workloads. Missing: subqueries in WHERE, FULL OUTER JOIN, foreign keys, triggers, stored procedures, multi-connection concurrency, network replication.

Exception: If your PostgreSQL use case is specifically an embedded analytical store with temporal requirements, TensorDB's 4.2x read speed advantage and native bitemporal support may justify it as a complement (not replacement).

5.4 Replace Oracle? NO

Criterion	Oracle	TensorDB
Enterprise HA	RAC, Data Guard	None
Partitioning	Range, Hash, List, Composite	4-shard fixed
PL/SQL	Yes	No
Flashback	Yes (similar concept)	AS OF EPOCH (simpler)
Encryption	TDE, network, column-level	AES-256-GCM (basic)
Audit	Oracle Audit Vault	Built-in (simpler)
Performance at scale	Millions of concurrent users	Single-process embedded
Support & SLA	24/7 enterprise	Open source
Regulatory certifications	SOC2, HIPAA, PCI-DSS	None

Why NOT: Oracle serves mission-critical enterprise workloads at massive scale with enterprise support, regulatory certifications, and decades of optimization. TensorDB is an embedded library — it operates in a fundamentally different tier. The comparison is architectural: Oracle is a networked multi-user RDBMS; TensorDB is an embedded single-process database.

---

6. Gaps and Risks

Critical Gaps (Production Blockers)

1. No multi-value INSERT — INSERT INTO t VALUES (1,'a'), (2,'b') unsupported. Must insert row-by-row. Major productivity and performance impact for ETL/batch workloads.

2. No subqueries in WHERE — WHERE x IN (SELECT ...) unsupported. Forces application-level workarounds for common query patterns.

3. No OFFSET — Pagination requires application-level cursor management.

4. No CREATE TABLE IF NOT EXISTS — Schema migration scripts cannot be idempotent.

5. No cross-call transaction sessions — BEGIN in one call, COMMIT in another doesn't work. All transaction statements must be in a single db.sql() invocation. This breaks every ORM and connection pool pattern.

6. No foreign keys — No referential integrity enforcement.

7. No triggers — No server-side reactive logic.

Moderate Gaps

8. No FULL OUTER JOIN — Available in most SQL databases.
9. No stored procedures — All logic must live in application code.
10. No SELECT without FROM — SELECT 1+1 requires a dummy table.
11. No network replication — Distributed crate exists but is experimental.
12. No connection pooling — Embedded only; pgwire server is basic.

Risks

13. Maturity — New database, limited production track record. No known large-scale deployments.
14. Single developer? — Bus factor risk. No visible enterprise support organization.
15. Batch write regression — Mixed workload benchmark showed 109% regression in one run (high variance suggests GC or compaction interference).
16. 50K LoC — Relatively small codebase for the feature surface area. May indicate shallow implementations in some areas.

---

7. Strengths Summary

1. Blazing fast reads: 263ns point read, 3.8M reads/s — competitive with the fastest embedded KV stores
2. Multi-model in one binary: SQL + full-text (BM25) + vector (HNSW) + time-series + event sourcing + CDC
3. Bitemporal by design: System time + business time, time travel queries, epoch-based PITR
4. Immutable ledger: Every write is a fact. Complete audit trail by architecture, not by bolt-on
5. Pure Rust: Zero C dependencies in default build. Memory safe, no GC pauses
6. Comprehensive observability: 8 SHOW diagnostic commands, EXPLAIN ANALYZE, health endpoint
7. Security: RBAC + RLS + audit log + GDPR erasure — unusual depth for an embedded DB
8. 800+ tests passing: Strong test coverage across 51 suites
9. Sub-microsecond writes: 2.6μs fast-path writes are exceptional

---

8. Final Verdict

Target System	Replace?	Confidence	Use Case Fit
SQLite	Yes, selectively	Medium	Temporal data, multi-model, high-throughput reads
Redis	Yes, selectively	Medium	Persistent embedded cache with SQL + temporal
PostgreSQL	No	High	Missing too many SQL features, no network multi-user
Oracle	No	Very High	Different tier entirely

Where TensorDB Should Be Deployed

• Embedded analytical stores with temporal requirements (audit, compliance, regulatory)
• Edge databases where a full RDBMS is too heavy but you need SQL + versioning
• Multi-model applications needing SQL + FTS + vector search in one library
• Append-only ledger systems (financial events, IoT sensor data, supply chain)

Where TensorDB Should NOT Be Deployed

• General-purpose OLTP replacing PostgreSQL/MySQL
• High-concurrency web application backends (no connection pooling, embedded-only)
• Mission-critical enterprise systems requiring vendor support and SLAs
• Workloads requiring complex SQL (nested subqueries, stored procedures, triggers)
• High-throughput batch ETL (no multi-value INSERT)

---

Report generated from 50 enterprise evaluation tests (all passing), 3 benchmark suites (comparative, multi_engine, basic), and full workspace test suite (800+ tests, 0 failures). All measurements taken on the same hardware under controlled conditions.