Compare the runtimes that power modern software.
OS processes, the JVM, Ethereum’s EVM, database engines, and the Web Platform all execute programs — but they differ radically in isolation, scheduling, state, determinism, and cost.
Five different answers to “how should code run?”
Use the filters to highlight the runtime best aligned with a particular goal.
OS Process
Native execution with kernel-managed resources and isolation.
- Execution
- Machine code
- Scheduling
- Preemptive OS threads
- State
- Memory + external storage
- Strength
- Maximum control
JVM
Managed, portable execution for Java-family languages.
- Execution
- Bytecode + JIT
- Scheduling
- Managed threads on OS
- State
- Heap + external storage
- Strength
- Safety and portability
Ethereum / EVM
Replicated, metered execution for smart-contract state transitions.
- Execution
- EVM bytecode
- Scheduling
- Transaction ordering
- State
- Blockchain world state
- Strength
- Verifiable consensus
Database Runtime
Transactional execution optimized around durable data.
- Execution
- SQL + query plans
- Scheduling
- Workload and transaction scheduler
- State
- Pages, logs, indexes
- Strength
- Consistency and recovery
Web Platform
Sandboxed event-driven execution for interactive applications.
- Execution
- JavaScript + WebAssembly
- Scheduling
- Tasks, microtasks, workers
- State
- DOM, browser storage, servers
- Strength
- Reach and user experience
The same word “runtime,” very different contracts
Scroll horizontally on smaller screens.
| Dimension | OS Process | JVM | Ethereum / EVM | Database Runtime | Web Platform |
|---|---|---|---|---|---|
| Primary purpose | Run native programs | Run managed applications | Execute consensus-safe contracts | Process queries and transactions | Run interactive client applications |
| Main unit | Process / thread | Thread / method invocation | Transaction / contract call | Session / statement / transaction | Document / task / worker |
| Memory | Virtual address space | Managed heap and stacks | Stack, transient memory, storage | Buffer pool and working memory | JS heap, DOM, rendering data |
| Persistence | External | External | Built into blockchain state | Core responsibility | Browser storage or remote service |
| Resource control | CPU, memory, quotas | Heap and GC policies | Gas | Timeouts and workload limits | Sandbox and responsiveness limits |
| Determinism | Generally no | Generally no | Required | Logical consistency, variable plans | Generally no |
| Isolation | Kernel boundary | Usually process-level | Protocol and contract rules | Roles and transaction isolation | Origin sandbox and browser processes |
| Best fit | Systems and native software | Enterprise and backend apps | Decentralized verifiable logic | Durable concurrent data | Cross-platform user interfaces |
Choose by the guarantee you need most
You need control and performance
Start with an OS process when low-level access, native libraries, and predictable hardware interaction matter most.
You need managed application development
Choose the JVM for mature tooling, garbage collection, portability, and strong support for large backend systems.
You need trusted shared state
Use the EVM only when replicated verification and decentralized ownership justify the cost and constraints.
You need durable concurrent data
A database runtime is the specialist for transactions, recovery, indexing, and optimized declarative queries.
You need maximum user reach
The Web Platform delivers interactive software through a secure sandbox on nearly every modern device.
You probably need several
Real systems combine runtimes: a browser talks to a JVM service, which uses a database and may call an EVM contract.