diff --git a/astro.config.mjs b/astro.config.mjs
index 9bda7bc7..6d48830b 100755
--- a/astro.config.mjs
+++ b/astro.config.mjs
@@ -226,6 +226,15 @@ export default defineConfig({
                         "migration/java/jedis/jedis-compatibility-layer/configurations-mapping",
                       ],
                     },
+                    {
+                      label: "Jedis 4.x Compatibility Layer",
+                      items: [
+                        "migration/java/jedis/jedis-4-compatibility-layer",
+                        "migration/java/jedis/jedis-4-compatibility-layer/instructions",
+                        "migration/java/jedis/jedis-4-compatibility-layer/supported-features",
+                        "migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping",
+                      ],
+                    },
                     {
                       label: "Manual Migrations",
                       items: [
diff --git a/src/content/docs/migration/java/jedis/index.mdx b/src/content/docs/migration/java/jedis/index.mdx
index 1389d83b..19b0de60 100644
--- a/src/content/docs/migration/java/jedis/index.mdx
+++ b/src/content/docs/migration/java/jedis/index.mdx
@@ -10,6 +10,8 @@ import { Aside, LinkCard } from '@astrojs/starlight/components';
 
 #### Looking to migrate from Jedis?
 
-<LinkCard title="Quick Migration" href={`/migration/java/jedis/jedis-compatibility-layer/`} description="A simple drop-in replacement using the Jedis Compatibility Layer." />
+<LinkCard title="Quick Migration (Jedis 5.x)" href={`/migration/java/jedis/jedis-compatibility-layer/`} description="A simple drop-in replacement using the Jedis Compatibility Layer for Jedis 5.x applications." />
+
+<LinkCard title="Quick Migration (Jedis 4.x)" href={`/migration/java/jedis/jedis-4-compatibility-layer/`} description="A drop-in replacement for Jedis 4.0.x–4.4.x applications using the Jedis 4.x Compatibility Layer." />
 
 <LinkCard title="Full Migration" href={`/migration/java/jedis/manual-migrations/`} description="Take full avantage of Valkey GLIDE by moving to native APIs." />
diff --git a/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping.mdx b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping.mdx
new file mode 100644
index 00000000..f449737b
--- /dev/null
+++ b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping.mdx
@@ -0,0 +1,104 @@
+---
+title: Configuration Mapping
+description: Configuration mapping between Jedis 4.x and the GLIDE Jedis 4.x Compatibility Layer.
+sidebar:
+  order: 4
+
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+This page describes how Jedis 4.x configuration parameters map to Valkey GLIDE configuration when using the Jedis 4.x Compatibility Layer.
+
+## Configuration Overview
+
+The following Jedis 4.x configuration parameters are:
+
+* **Successfully Mapped**: user, password, clientName, ssl, connectionTimeoutMillis, socketTimeoutMillis, database.
+* **Accepted but Ignored**: redisProtocol (always RESP2), pool configuration values.
+* **Not Supported**: Custom SSLSocketFactory, HostnameVerifier, keystore/truststore, cipher suites, TLS protocol versions, client-auth, AuthXManager, custom RedisCredentialsProvider.
+
+## Parameter Mappings
+
+### `DefaultJedisClientConfig` Parameters
+
+| Jedis 4.x Parameter | GLIDE Mapping | Notes |
+|---|---|---|
+| `user` | `ServerCredentials.username` | Fully supported |
+| `password` | `ServerCredentials.password` | Fully supported |
+| `clientName` | `BaseClientConfiguration.clientName` | Fully supported |
+| `ssl` | `BaseClientConfiguration.useTLS` | System trust store only |
+| `connectionTimeoutMillis` | `AdvancedBaseClientConfiguration.connectionTimeout` | Fully supported |
+| `socketTimeoutMillis` | `BaseClientConfiguration.requestTimeout` | Fully supported |
+| `database` | Handled via SELECT command after connection | Fully supported |
+| `redisProtocol` / `getRedisProtocol()` | Ignored | Always RESP2; exists for source compatibility |
+
+### Pool Configuration Parameters
+
+<Aside type="note" title="Pool config is accepted but ignored">
+  GLIDE manages connection pooling internally. Apache Commons Pool settings are accepted at the API level for compatibility but have no effect on GLIDE's behavior.
+</Aside>
+
+| Jedis 4.x Pool Parameter | GLIDE Behavior |
+|---|---|
+| `maxTotal` | Ignored — GLIDE manages pool size internally |
+| `maxIdle` | Ignored |
+| `minIdle` | Ignored |
+| `maxWaitMillis` | Ignored |
+| `testOnBorrow` | Ignored |
+| `testOnReturn` | Ignored |
+| `testWhileIdle` | Ignored |
+| `timeBetweenEvictionRunsMillis` | Ignored |
+| `numTestsPerEvictionRun` | Ignored |
+| `minEvictableIdleTimeMillis` | Ignored |
+| `blockWhenExhausted` | Ignored |
+
+### Pool Type Differences
+
+| Client | Jedis 4.x Pool Type | Jedis 5.x Pool Type |
+|---|---|---|
+| `JedisPool` | `GenericObjectPoolConfig<Jedis>` | `GenericObjectPoolConfig<Jedis>` |
+| `JedisPooled` | `GenericObjectPoolConfig<Connection>` | `GenericObjectPoolConfig<Object>` |
+
+Both types are accepted by this compatibility layer and both are ignored internally.
+
+## SSL/TLS Configuration
+
+### Supported
+
+| Configuration | Example |
+|---|---|
+| Enable TLS (system trust store) | `DefaultJedisClientConfig.builder().ssl(true).build()` |
+| `rediss://` URI scheme | `new JedisPooled("rediss://localhost:6380")` |
+| Insecure mode (testing only) | `SslOptions.builder().sslVerifyMode(SslVerifyMode.INSECURE).build()` |
+
+### Not Supported (throws `JedisConfigurationException`)
+
+| Configuration | Alternative |
+|---|---|
+| Custom `SSLSocketFactory` | Use system trust store or native GLIDE config |
+| Custom `HostnameVerifier` | Use system trust store or `SslVerifyMode.INSECURE` for testing |
+| Keystore / truststore on `SslOptions` | Install certificates in the system trust store |
+| Custom cipher suites | GLIDE auto-selects secure ciphers |
+| TLS protocol version selection | GLIDE auto-selects TLS 1.2+ |
+| Client-auth flags on `SSLParameters` | Use username/password authentication |
+
+## Cluster Configuration
+
+### `JedisCluster` Constructor Parameters
+
+| Parameter | GLIDE Mapping | Notes |
+|---|---|---|
+| `Set<HostAndPort> nodes` | Cluster node addresses | Fully supported |
+| `connectionTimeout` | Connection timeout | Fully supported |
+| `soTimeout` | Socket/request timeout | Fully supported |
+| `maxAttempts` | Retry configuration | Mapped to GLIDE retry strategy |
+| `password` | Authentication credentials | Fully supported |
+| `clientName` | Client name | Fully supported |
+
+## Key Migration Insights
+
+1. **Pool configuration doesn't matter**: GLIDE's internal connection management is optimized and ignores pool settings. This is usually an improvement over manually tuned pools.
+2. **Protocol is always RESP2**: The `.protocol()` method exists for source compatibility with shared config types, but GLIDE always negotiates RESP2 in this layer. For RESP3, use the Jedis 5.x layer.
+3. **SSL simplified**: GLIDE uses system certificate stores with secure defaults (TLS 1.2+, modern cipher suites). Custom SSL configuration must be migrated to system-level trust or to native GLIDE APIs.
+4. **Timeouts map directly**: Connection and socket timeouts are mapped to GLIDE's equivalent timeout settings with the same semantics.
diff --git a/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/index.mdx b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/index.mdx
new file mode 100644
index 00000000..ceafc053
--- /dev/null
+++ b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/index.mdx
@@ -0,0 +1,80 @@
+---
+title: Overview
+description: Learn how the Valkey GLIDE Jedis 4.x Compatibility Layer enables seamless migration from Jedis 4.x to Valkey GLIDE with minimal or no code changes.
+sidebar:
+  order: 1
+
+---
+
+import { Aside, LinkCard } from '@astrojs/starlight/components';
+
+The Valkey GLIDE Jedis 4.x Compatibility Layer is a **drop-in replacement** that enables seamless migration from Jedis 4.x applications to Valkey GLIDE with minimal or no code changes.
+
+It implements the Jedis 4.x API while using the high-performance Valkey GLIDE client underneath. This allows existing Jedis 4.x applications to benefit from GLIDE's modern architecture without a complete rewrite.
+
+<Aside type="note" title="Which compatibility layer do I need?">
+  This layer targets **Jedis 4.0.x through 4.4.x** applications. If your application already uses **Jedis 5.x** APIs (e.g., `GenericObjectPoolConfig<Object>` for `JedisPooled`, RESP3 support), use the [Jedis Compatibility Layer](/migration/java/jedis/jedis-compatibility-layer/) instead.
+</Aside>
+
+## Why a Separate Jedis 4.x Layer?
+
+Jedis 5.x introduced breaking changes to several public types — notably `JedisPooled` pool generics changed from `GenericObjectPoolConfig<Connection>` to `GenericObjectPoolConfig<Object>`, and optional RESP3 / `RedisProtocol` APIs were added.
+
+Applications compiled against Jedis 4.x signatures need this module. You pick **one** GLIDE compatibility artifact that matches your existing API:
+
+| Your Jedis Version | GLIDE Compatibility Artifact |
+|---|---|
+| 4.0.x – 4.4.x | `valkey-glide-jedis-4-compatibility` |
+| 5.0.x – 5.2.x | `valkey-glide-jedis-compatibility` |
+
+## Zero-Code Migration
+
+For applications using standard Redis commands, migration can be as simple as changing a single dependency in your build configuration. Your existing Jedis 4.x code continues to work without modification:
+
+```java
+import redis.clients.jedis.Jedis;
+import redis.clients.jedis.JedisPool;
+import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
+
+// Jedis 4.x style - GenericObjectPoolConfig<Jedis>
+GenericObjectPoolConfig<Jedis> poolConfig = new GenericObjectPoolConfig<>();
+poolConfig.setMaxTotal(8);
+
+try (JedisPool pool = new JedisPool(poolConfig, "localhost", 6379)) {
+    try (Jedis jedis = pool.getResource()) {
+        jedis.set("key", "value");
+        String result = jedis.get("key");
+    }
+}
+```
+
+## Key Benefits
+
+* **Reduced Effort:** Eliminates the need to rewrite most application code, saving development time, reducing testing, and lowering migration risk.
+* **Gradual Migration:** Start by swapping the dependency. Later, you can incrementally migrate complex features to native GLIDE APIs at your own pace.
+* **Business Continuity:** Avoid "big-bang" rewrites. Deploy changes incrementally with minimal downtime and the ability to roll back easily.
+* **Faster Time-to-Value:** Immediately benefit from GLIDE's modern async I/O model and optimized performance.
+* **RESP2 Protocol:** Always uses RESP2 protocol, matching Jedis 4.x default behavior.
+
+## Limitations
+
+The compatibility layer is essentially **a wrapper** around Valkey GLIDE that implements the Jedis 4.x interface.
+As such, not all Jedis and Valkey GLIDE features are supported.
+
+Key limitations include:
+- **Connection pooling**: GLIDE manages pooling internally — pool configuration values are accepted but ignored.
+- **Protocol**: Always RESP2. For RESP3, upgrade to Jedis 5.x and use the Jedis 5.x compatibility layer.
+- **SSL/TLS**: Basic TLS via `ssl(true)` and `rediss://` URIs is supported (system trust store). Custom `SSLSocketFactory`, `HostnameVerifier`, keystore/truststore, cipher suites, and client-auth are **not** supported.
+- **AuthXManager**: Not supported. Use standard username/password authentication.
+
+For simple applications, the wrapper may be enough. For applications that need advanced features or want to take full advantage of Valkey GLIDE, a full migration to the native GLIDE API is recommended.
+
+## Next Steps
+
+Ready to get started?
+
+<LinkCard title="Migration Instructions" href={`/migration/java/jedis/jedis-4-compatibility-layer/instructions/`} description="Step-by-step instructions for migrating from Jedis 4.x using the compatibility layer." />
+
+<LinkCard title="Supported Features" href={`/migration/java/jedis/jedis-4-compatibility-layer/supported-features/`} description="See what Jedis 4.x features and commands are supported." />
+
+<LinkCard title="Configuration Mapping" href={`/migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping/`} description="How Jedis 4.x configurations map to Valkey GLIDE configurations." />
diff --git a/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/instructions.mdx b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/instructions.mdx
new file mode 100644
index 00000000..b6d663a7
--- /dev/null
+++ b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/instructions.mdx
@@ -0,0 +1,225 @@
+---
+title: Migration Guide
+description: Learn the steps and strategies for migrating from Jedis 4.x to GLIDE using the Jedis 4.x Compatibility Layer.
+sidebar:
+  order: 2
+
+---
+
+import { Aside, Tabs, TabItem, LinkCard } from '@astrojs/starlight/components';
+
+This section outlines the steps and strategies for migrating from Jedis 4.x to Valkey GLIDE using the Jedis 4.x Compatibility Layer.
+
+## Instructions
+
+The migration can be done by replacing the `jedis` 4.x dependency with `valkey-glide-jedis-4-compatibility`.
+
+<Aside type="caution" title="Platform classifier required">
+  Unlike the Jedis 5.x compatibility layer, the Jedis 4.x compatibility layer currently requires a platform classifier. Choose the classifier matching your deployment platform.
+</Aside>
+
+**Available platform classifiers:**
+
+| Platform | Classifier |
+|---|---|
+| macOS ARM64 (Apple Silicon) | `osx-aarch_64` |
+| macOS x86_64 (Intel) | `osx-x86_64` |
+| Linux ARM64 | `linux-aarch_64` |
+| Linux x86_64 | `linux-x86_64` |
+| Windows x86_64 | `win32-x86-64` |
+
+<Tabs>
+  <TabItem label="Gradle">
+    ```diff lang="groovy"
+    dependencies {
+    -    implementation 'redis.clients:jedis:4.4.8'
+    +    implementation group: 'io.valkey', name: 'valkey-glide-jedis-4-compatibility', version: '2.1.0', classifier: 'linux-x86_64'
+    }
+    ```
+  </TabItem>
+
+  <TabItem label="Maven">
+    ```diff lang="xml"
+    <dependency>
+    -    <groupId>redis.clients</groupId>
+    -    <artifactId>jedis</artifactId>
+    -    <version>4.4.8</version>
+    +    <groupId>io.valkey</groupId>
+    +    <artifactId>valkey-glide-jedis-4-compatibility</artifactId>
+    +    <version>2.1.0</version>
+    +    <classifier>linux-x86_64</classifier>
+    </dependency>
+    ```
+  </TabItem>
+</Tabs>
+
+After updating the dependency, your existing Jedis 4.x code should compile without modification as the compatibility layer is a drop-in replacement for Jedis 4.x.
+
+```java
+import redis.clients.jedis.Jedis;
+import redis.clients.jedis.JedisPool;
+import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
+
+// Jedis 4.x style - GenericObjectPoolConfig<Jedis>
+GenericObjectPoolConfig<Jedis> poolConfig = new GenericObjectPoolConfig<>();
+poolConfig.setMaxTotal(8);
+
+try (JedisPool pool = new JedisPool(poolConfig, "localhost", 6379)) {
+    try (Jedis jedis = pool.getResource()) {
+        jedis.set("key", "value");
+        String result = jedis.get("key");
+    }
+}
+```
+
+<Aside type="tip">
+  Deployed applications can be migrated by replacing the Jedis JAR with the Valkey GLIDE JAR and the compatibility layer JAR in the application's classpath.
+</Aside>
+
+## Common Migration Scenarios
+
+### JedisPooled (Jedis 4.x Style)
+
+The key difference between Jedis 4.x and 5.x is the `JedisPooled` generic type. Jedis 4.x uses `GenericObjectPoolConfig<Connection>`:
+
+```java
+import redis.clients.jedis.Connection;
+import redis.clients.jedis.JedisPooled;
+import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
+
+// Jedis 4.x style - GenericObjectPoolConfig<Connection>
+GenericObjectPoolConfig<Connection> poolConfig = new GenericObjectPoolConfig<>();
+poolConfig.setMaxTotal(16);
+
+try (JedisPooled jedis = new JedisPooled(poolConfig, "localhost", 6379, 2000, "password")) {
+    jedis.set("key", "value");
+    String value = jedis.get("key");
+}
+```
+
+This code works **unchanged** with the Jedis 4.x compatibility layer.
+
+### JedisCluster
+
+```java
+import redis.clients.jedis.JedisCluster;
+import redis.clients.jedis.HostAndPort;
+import java.util.HashSet;
+import java.util.Set;
+
+Set<HostAndPort> nodes = new HashSet<>();
+nodes.add(new HostAndPort("localhost", 7000));
+nodes.add(new HostAndPort("localhost", 7001));
+nodes.add(new HostAndPort("localhost", 7002));
+
+JedisCluster jedisCluster = new JedisCluster(nodes, 2000, 2000, 5, "password", "default");
+
+jedisCluster.set("key", "value");
+String value = jedisCluster.get("key");
+```
+
+### UnifiedJedis
+
+```java
+import redis.clients.jedis.UnifiedJedis;
+
+try (UnifiedJedis jedis = new UnifiedJedis("localhost", 6379)) {
+    jedis.set("key", "value");
+    String value = jedis.get("key");
+}
+```
+
+### SSL/TLS Connection
+
+```java
+import redis.clients.jedis.DefaultJedisClientConfig;
+import redis.clients.jedis.JedisClientConfig;
+import redis.clients.jedis.JedisPooled;
+
+// TLS using system trust store
+JedisClientConfig config = DefaultJedisClientConfig.builder()
+    .ssl(true)
+    .build();
+
+// Or use rediss:// URI scheme
+JedisPooled jedis = new JedisPooled("rediss://localhost:6380");
+```
+
+<Aside type="caution" title="TLS limitations">
+  Only basic TLS via system trust store is supported. Custom `SSLSocketFactory`, `HostnameVerifier`, keystore/truststore, cipher suites, TLS protocol versions, and client-auth are **not** supported and will throw `JedisConfigurationException` at client creation.
+</Aside>
+
+## Testing Your Application
+
+After migration, it is crucial to thoroughly evaluate your application to ensure compatibility and stability.
+
+1. **Test All Code Paths:** Do not rely on successful compilation. Test every part of your application that interacts with Jedis, not just simple `get`/`set` operations.
+2. **Monitor for Runtime Exceptions:** Specifically watch for errors from unsupported or stubbed methods.
+3. **Start with simple operations**: Keep it simple first by verifying basic compatibility.
+
+## Migration Checklist
+
+1. **Check your Jedis version** — ensure you are on Jedis 4.0.x through 4.4.x. If on Jedis 5.x, use the [Jedis Compatibility Layer](/migration/java/jedis/jedis-compatibility-layer/) instead.
+2. **Audit your codebase** for unsupported features. See the <a href={`/migration/java/jedis/jedis-4-compatibility-layer/supported-features/`}>Supported Features</a> section for details.
+3. **Replace the dependency** with `valkey-glide-jedis-4-compatibility` and the correct platform classifier.
+4. **Test thoroughly** in a development environment.
+5. **Review connection configurations** for compatibility. See the <a href={`/migration/java/jedis/jedis-4-compatibility-layer/configurations-mapping/`}>Configuration Mapping</a> page.
+6. **Plan for feature gaps** that may require code changes (especially custom SSL/TLS, AuthXManager, custom credential providers).
+7. **Expect pool config to be ignored** — GLIDE manages pooling internally.
+8. **Verify protocol behavior** — `.protocol()` and `getRedisProtocol()` exist for source compatibility but are ignored (always RESP2).
+
+## Migration Strategies
+
+1. Start with simple applications using basic commands.
+2. Gradually migrate complex features to native Valkey GLIDE APIs.
+3. Consider using Valkey GLIDE native APIs for unsupported features.
+4. Monitor performance and behavior differences.
+
+<Aside type="tip" title="Have a Rollback Plan">
+  Be prepared to revert to your original Jedis 4.x dependency if you discover critical incompatibilities. Simply swap the dependency back to `redis.clients:jedis:4.x.x` and rebuild.
+</Aside>
+
+## Troubleshooting
+
+### Compilation Error: Cannot find symbol `GenericObjectPoolConfig<Connection>`
+
+**Solution:** You may be accidentally using the Jedis 5.x compatibility layer. Switch to `jedis-4-compatibility`:
+
+<Tabs>
+  <TabItem label="Gradle">
+    ```groovy
+    // Change from:
+    implementation 'io.valkey:valkey-glide-jedis-compatibility:2.1.0'
+
+    // To:
+    implementation group: 'io.valkey', name: 'valkey-glide-jedis-4-compatibility', version: '2.1.0', classifier: 'linux-x86_64'
+    ```
+  </TabItem>
+
+  <TabItem label="Maven">
+    ```xml
+    <!-- Change from: -->
+    <artifactId>valkey-glide-jedis-compatibility</artifactId>
+
+    <!-- To: -->
+    <artifactId>valkey-glide-jedis-4-compatibility</artifactId>
+    <classifier>linux-x86_64</classifier>
+    ```
+  </TabItem>
+</Tabs>
+
+### Need RESP3 support
+
+RESP3 is not available in the Jedis 4.x compatibility layer. To use RESP3, upgrade your application to Jedis 5.x APIs and use the [Jedis Compatibility Layer](/migration/java/jedis/jedis-compatibility-layer/) instead.
+
+### Tests fail with connection errors
+
+- Check that your Redis/Valkey server is running and accessible
+- Verify connection parameters (host, port, password)
+- Review GLIDE logs for connection errors
+
+## Manual Migration
+
+If your application relies heavily on unsupported features or you want the maximum performance and features of GLIDE, consider a **manual migration** directly to the native API.
+
+<LinkCard title="Manual Migration" href={`/migration/java/jedis/manual-migrations/`} description="Migrate from Jedis to Valkey GLIDE using native APIs for full feature support." />
diff --git a/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/supported-features.mdx b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/supported-features.mdx
new file mode 100644
index 00000000..a6313550
--- /dev/null
+++ b/src/content/docs/migration/java/jedis/jedis-4-compatibility-layer/supported-features.mdx
@@ -0,0 +1,118 @@
+---
+title: Supported Features
+description: A list of supported features in the GLIDE Jedis 4.x Compatibility Layer.
+sidebar:
+  order: 3
+
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## Supported Features
+
+### Client Types
+
+* ✅ `Jedis` — Basic client
+* ✅ `JedisPool` — Connection pooling with `GenericObjectPoolConfig<Jedis>`
+* ✅ `JedisPooled` — Pooled client with `GenericObjectPoolConfig<Connection>` (Jedis 4.x style)
+* ✅ `JedisCluster` — Cluster client with `Set<HostAndPort>` initialization
+* ✅ `UnifiedJedis` — Unified interface for standalone and cluster operations
+
+### Core Commands
+
+* ✅ Basic string operations (GET, SET, MGET, MSET, APPEND, INCR, DECR, etc.)
+* ✅ Hash operations (HGET, HSET, HMGET, HMSET, HDEL, HGETALL, etc.)
+* ✅ List operations (LPUSH, RPUSH, LPOP, RPOP, LRANGE, LLEN, etc.)
+* ✅ Set operations (SADD, SREM, SMEMBERS, SISMEMBER, etc.)
+* ✅ Sorted set operations (ZADD, ZREM, ZRANGE, ZSCORE, etc.)
+* ✅ Key operations (DEL, EXISTS, EXPIRE, TTL, KEYS, SCAN, etc.)
+* ✅ Connection commands (PING, SELECT, AUTH)
+* ✅ Generic commands via `sendCommand()` (Protocol.Command types only)
+
+### Advanced Features
+
+* ✅ Transactions (MULTI/EXEC)
+* ✅ Pipelining
+* ✅ Pub/Sub (publish/subscribe)
+* ✅ Cluster mode (standalone and cluster deployment)
+
+### Configuration
+
+* ✅ Host and port configuration
+* ✅ Basic authentication (username/password)
+* ✅ Database selection
+* ✅ Connection timeout
+* ✅ Socket timeout
+* ✅ SSL/TLS via `ssl(true)` and `rediss://` URIs (system trust store)
+
+<Aside type="note" title="Pool configuration">
+  Connection pool settings (`maxTotal`, `maxIdle`, `minIdle`, eviction policies, etc.) are accepted for API compatibility but **ignored at runtime**. GLIDE manages connection pooling internally with its own optimized strategy.
+</Aside>
+
+## Key Differences from Jedis 5.x Compatibility Layer
+
+| Feature | Jedis 4.x Layer | Jedis 5.x Layer |
+|---|---|---|
+| `JedisPooled` generic type | `GenericObjectPoolConfig<Connection>` | `GenericObjectPoolConfig<Object>` |
+| Protocol | RESP2 only | RESP2 (default) or RESP3 |
+| `.protocol()` / `getRedisProtocol()` | Present for source compatibility; **ignored** | Honored |
+| Target Jedis version | 4.0.x – 4.4.x | 5.0.x – 5.2.x |
+| Platform classifier | Required | Not required (since 2.4.0) |
+
+## Unsupported Features
+
+### SSL/TLS Limitations
+
+* ❌ Custom `SSLSocketFactory`
+* ❌ Custom `HostnameVerifier`
+* ❌ Keystore / truststore resources on `SslOptions`
+* ❌ Custom cipher suites
+* ❌ TLS protocol version selection
+* ❌ Client-auth flags on `SSLParameters`
+* ❌ Endpoint identification algorithms (custom)
+
+<Aside type="caution" title="Unsupported SSL throws at creation time">
+  If your Jedis 4.x app sets any of the unsupported SSL/TLS options above, client creation will throw `JedisConfigurationException`. Migrate those call sites to system-truststore TLS or to native GLIDE client configuration before swapping the dependency.
+</Aside>
+
+### Authentication Limitations
+
+* ❌ `AuthXManager` — Not supported
+* ❌ Custom `RedisCredentialsProvider` implementations
+
+### Connection Management
+
+* ⚠️ Pool configuration values are accepted but **ignored** (GLIDE manages pooling internally)
+* ❌ Custom `JedisSocketFactory` implementations (accepted but not used)
+* ❌ Connection validation / health checks (Jedis-style)
+
+### Protocol Limitations
+
+* ❌ RESP3 protocol — Always uses RESP2
+* ⚠️ `.protocol(RESP3)` compiles but is ignored; connection always negotiates RESP2
+
+### Other Limitations
+
+* ❌ Custom serializers
+* ❌ Jedis-specific retry logic
+* ❌ Custom `ProtocolCommand` implementations (only `Protocol.Command` types via `sendCommand()`)
+
+## Deployment Modes
+
+| Mode | Supported |
+|---|---|
+| Standalone | ✅ |
+| Cluster | ✅ |
+| Sentinel | ⚠️ Limited |
+
+## Platform Support
+
+The Jedis 4.x compatibility layer requires a platform-specific classifier:
+
+| Platform | Classifier |
+|---|---|
+| macOS ARM64 (Apple Silicon) | `osx-aarch_64` |
+| macOS x86_64 (Intel) | `osx-x86_64` |
+| Linux ARM64 | `linux-aarch_64` |
+| Linux x86_64 | `linux-x86_64` |
+| Windows x86_64 | `win32-x86-64` |