Skip to content

When to Use SensibleDB

This document helps you determine when SensibleDB is the right choice for your application versus when a more specialized or traditional database approach might be better.

Ideal Use Cases for SensibleDB

AI-Powered Applications

SensibleDB excels when building applications that require: - Retrieval-Augmented Generation (RAG): Combining semantic search with generative AI - Intelligent Agents: Systems that need to understand relationships between entities - Knowledge Graphs: Representing and querying interconnected information - Semantic Search: Finding information by meaning rather than exact keywords - Recommendation Systems: Leveraging both content similarity and relationship patterns

Applications Benefiting from Multi-Model Data

Consider SensibleDB when your data naturally fits multiple models: - Entities with Attributes: Traditional document/relational data - Relationships Between Entities: Graph connections and traversals - Semantic Meaning: Vector representations for similarity search - Temporal Aspects: Time-series data and temporal relationships

Development and Operational Benefits

SensibleDB provides advantages when you value: - Reduced Operational Complexity: Single database instead of multiple specialized systems - Development Velocity: Fewer moving parts and integration points - Consistency Guarantees: ACID transactions across all data models - Performance Characteristics: Optimized for the access patterns of AI workloads - Deployment Simplicity: Embedded mode for easy distribution

When SensibleDB Might Not Be the Best Choice

Pure Relational Workloads

If your application is primarily: - Traditional CRUD operations on structured data - Heavy use of complex SQL joins and transactions - Established relational schemas with normalization requirements - Reporting and business intelligence workloads Consider: PostgreSQL, MySQL, or other mature RDBMS solutions

Specialized High-Performance Needs

For workloads requiring extreme specialization: - Pure Vector Search at Scale: Applications needing billions of vectors with millisecond latency - Graph Analytics at Scale: Massive graph processing with complex algorithms - High-Volume Logging/Telemetry: Write-heavy workloads with simple query patterns Consider: Specialized systems like Milvus (vectors), JanusGraph (graphs), or TimescaleDB (time-series)

Legacy System Integration

When dealing with: - Strict requirements for specific SQL dialects or features - Dependencies on specific database extensions or stored procedures - Organizational standardized on particular database technologies Consider: Evaluating compatibility layers or gradual migration strategies

Decision Framework

Choose SensibleDB When:

  1. You're building AI/RAG applications that need both relationships and similarity search
  2. You want to reduce the number of databases in your architecture
  3. You value type safety and compile-time query validation
  4. You're working in the Rust ecosystem or can adopt it
  5. You need embedded database capabilities for distribution
  6. Your workload involves traversing relationships while considering semantic similarity

Consider Alternatives When:

  1. Your primary workload is traditional business reporting with complex SQL
  2. You need proven, decades-old battle-tested reliability for financial systems
  3. Your team has deep expertise in specific existing technologies
  4. You require specific features only available in mature specialized systems
  5. You're operating under strict regulatory requirements mandating specific databases

Hybrid Approaches

SensibleDB can work alongside other systems in complementary roles: - Primary AI Database: SensibleDB for AI-specific workloads - System of Record: Traditional DB for financial/user account data - Cache Layer: Redis for hot data that doesn't need persistence - Search Engine: Elasticsearch for full-text search when needed - Data Warehouse: Specialized OLAP systems for analytics

The key is using each system for what it does best while minimizing unnecessary complexity.

Evaluation Checklist

When evaluating SensibleDB for your project, consider: - [] Does your data benefit from both graph relationships and vector similarity? - [ ] Are you building AI agents, RAG systems, or knowledge graphs? - [ ] Would reducing database complexity improve development velocity? - [ ] Is the Rust ecosystem a fit for your team and deployment targets? - [ ] Do you need embedded database capabilities for distribution? - [ ] Are your performance requirements aligned with SensibleDB's strengths? - [ ] Do you value type safety and compile-time guarantees? - [ ] Is operational simplicity a priority for your team?

Answering "yes" to several of these questions suggests SensibleDB is worth serious consideration for your project.