Jakarta NoSQL 2026 [Proposal]

Jakarta NoSQL 2026 [Proposal]

Transcript

1. Jakarta NoSQL: Standardizing the AI Era A Strategic Proposal for Jakarta EE 12 Inclusion Otávio Santana
2.       NoSQL is no longer just documents or key-value caches. It spans six structural paradigms: Key-Value Ultra-low latency lookups. Ideal for web sessions and volatile caches. Document Stores rich hierarchical JSON/BSON natively. Built for fast application entities. Column-Family High-throughput, distributed write performance for massive IoT logging streams. Graph Maps deep, hyper-connected networks of metadata relationships directly. Vector Databases The Engine of AI. Stores mathematical embeddings for semantic search and LLM context. Time Series Tracks sequence telemetry timestamps sequentially over active timelines. WHAT IS NOSQL? THE MODERN TYPES
3. Real-world industry insights among Professional Developers highlight structural coexistence: Source: Stack Overflow Survey 2025. Polyglot persistence is the baseline architectural reality. THE DEVELOPER STACK (STACK OVERFLOW)
4. Alternative Java runtimes recognized the polyglot movement years ago and provided separate isolation layers: Jakarta EE is the only major platform missing an open, vendor-neutral persistence specification for NoSQL. Spring Data NoSQL Uses highly fragmented, isolated independent framework modules (Spring Data MongoDB, Spring Data Redis, etc.). Locks systems into proprietary spring container conventions. Quarkus Panache Implements rapid Active-Record patterns specifically optimized for single engines like MongoDB. Ideal for microservices but lacks cross-vendor platform portability. Micronaut Data Leverages ahead-of-time compilation parameters for document engines. Highly performant, but limits engineering tasks within custom build pipelines. CURRENT JAVA LANDSCAPE FRAGMENTATION
5. THE COST OF FRAGMENTATION The Productivity Tax Without standard enterprise NoSQL APIs, companies suffer severe performance and developer velocity penalties: Massive boilerplate code spent converting custom vendor drivers. Total vendor lock-in to proprietary SDK ecosystems. Endless developer retraining cycles whenever a database engine shifts. -40% Developer Velocity Drop Source: McKinsey & Company Developer Velocity Index (DVI) Research on ecosystem non-standardization friction.
6. LEXICAL VS. SEMANTIC SEARCH  SQL: Lexical Match Relies on exact string comparisons (LIKE/CONTAINS). Query: "Pet" Result: "Dog" (No Match) Result: "Puppy" (No Match) Result: "Pet Shop"  Vector: Semantic Match Understands intent via high-dimensional embeddings. Query: "Pet" Result: "Dog" (Similar Context) Result: "Puppy" (Semantic Match) Result: "Animal Companion" Vector Databases fit better because they capture Meaning, not just Syntax.
7. THE VECTOR DB AI MANDATE The AI Engine Vector databases are the undisputed leaders in AI. • Handles complex embedding similarity. • Powers RAG (Retrieval-Augmented Gen). • Prevents platform abandonment for AI apps.
8. Why Relational Fails AI Artificial Intelligence doesn't look at data through columns and tables. High-dimensional vector embeddings generated by LLMs require similarity calculations (like Cosine distance) across millions of coordinates instantly. Relational systems suffer massive compute penalties attempting this; Vector databases are the undisputed leaders here. The Strategic Mandate If Jakarta EE remains exclusively tied to Relational (JPA) frameworks, enterprise developers will abandon the ecosystem to build modern AI and RAG (Retrieval-Augmented Generation) architectures on alternative, non-Java stacks. AI WORKLOADS: VECTOR DATABASES LEAD
9. Jakarta Data Was Born Here The need to standardize NoSQL paradigms is the exact catalyst that inspired the unified Jakarta Data repository pattern. Unified Repositories Developers use a consistent programming model. Swap out underlying engine structures smoothly without restructuring the business tier logic. The Need for Jakarta Query Introduces type-safe, fluent database interaction. Generates queries securely at compile-time, bringing strict validation across highly flexible environments. THE SOLUTION: JAKARTA NOSQL BENEFITS
10. SMART ARCHITECTURE: OPTIONAL COMM LAYER Focus on Where Java Excels: Mapping We cannot control proprietary vendor drivers, nor can we predict how every emerging database will handle serialization protocols.  Optional Communication Layer: Provides decoupled hooks without forcing strict connection pipelines on vendors.  Foundation on Java Strength: Focuses explicitly on making the Mapping Layer bulletproof.  Leverages Java’s rich type system, CDI, and annotations to create an unshakeable developer interface, regardless of wire protocol. Jakarta NoSQL Tiering Mapping Layer (Strong Java Foundation) Communication Layer (Decoupled & Optional) Allows the platform to adapt smoothly to new engines without breaking specs.
11.  JDBC: Single-Way Serialization JDBC functions on a singular, monolithic assumption: communication serialization always travels a single path. It translates everything into rigid text-based SQL queries and flat tabular result streams over standard connections. Polyglot Driver Reality NoSQL engines use wildly complex, asynchronous serialization formats: • Binary BSON • Graph protocols • REST & gRPC streaming Forcing them through the singular pipeline of JDBC fundamentally cripples their native power and optimizations. THE JDBC BARRIER
12. WHY NOT OVERLOAD JPA? 1. Built Purely for SQL JPA relies on relational invariants. Forcing NoSQL schemas inside it compromises structural speed. 2. Divergent Behaviors Custom write guarantees, graph path traversals, or document structures alter transactional expectations radically. 3. Particular Behavior Matters Forcing a uniform API strips away the unique underlying optimizations of specific non-relational engines. The Unified Vehicle Fallacy Trying to design a single cockpit for a boat, plane, sub, and car forced to use the exact same controls. Boat Plane Sub Car One size does NOT fit all in database architecture.
13. FAMILIAR BUT DISTINCT MAPPING Comfortable Transition The annotations feel immediate to any Jakarta Persistence developer, minimizing technical friction. The Core Difference: Underneath the hood, these fields handle schema flexibility, non-tabular nested properties, and schema-agnostic structures gracefully without strict database-enforced schemas. @Entity public class Car { @Id private Long id; @Column private String name; @Column private CarType type; // Standard getters, setters... }
14. EXTREME VELOCITY: TEMPLATE API // Example Code @Inject Template template; Car ferrari = Car.builder().id(1L).name( "Ferrari").build(); template.insert(ferrari); // Fluent API List<Car> sports = template.select( Car.class) .where("type").eq(CarType.SPORT) .orderBy("name").result(); Radical Boilerplate Reduction No messy string concatenations, manually opened connections, or manual mapping pipelines. The fluent structural pattern enables compile-time safety across different polyglot configurations seamlessly.
15. JAKARTA NOSQL 1.1: JAKARTA QUERY Parameterized Security Safely bind application parameters to text queries, preventing code injections across distributed structures. Native Projections Extract focused view schemas directly into lightweight immutable Java record classes. // Secure Parameter Binding List<Car> cars = template.query( "FROM Car WHERE type = :type") .bind("type", CarType.SPORT) .result(); // Clean Immutable Projections via Java Records @Projection public record TechCarView(String name, CarType type) {} List<TechCarView> views = template .typedQuery("FROM Car WHERE type = 'SPORT'" , TechCarView.class) .result();
16. DocumentManagerFactory factory = ...; DocumentManager manager = factory.get( "users"); DocumentRecord record = ...; manager.put(record); Optional<DocumentRecord > result = manager.findByKey( "user:10"); manager.deleteByKey( "user:10"); Pluggable Core Modules When custom performance tuning is necessary, the low-level API speaks directly to operational wire boundaries. Current Options: Document, Key-Value, Column, and Graph modules. Multi-engine extensibility allows more blueprints to join smoothly. LOW-LEVEL COMMUNICATION API
17. Jakarta NoSQL 1.1 Target Platform: Jakarta EE 12 Jakarta NoSQL 1.2 Target Platform: Jakarta EE 13 Update baseline dependencies & Java version support. Standardized Driver Comm API: Unifies/simplifies NoSQL vendor vendor extensions. Jakarta Query Support: Portability for fluent query structures. Prepared Statement Support: Parameterized security boundaries. Support for nested Map embedded entity mappings. Vector & Time-Series: Standardized communication APIs. Jakarta Batch Integration: High-throughput data orchestration. Jakarta Configuration Integration: Centralized externalized properties. Agentic API Support: Indigenous abstractions for active AI systems. THE STRATEGIC ROADMAP