Store identical bytes once.
Deduplicated blob storage for Spring Boot, backed by your own database and object store.
<dependency>
<groupId>io.github.heyedem</groupId>
<artifactId>dedup4j-spring-boot-starter</artifactId>
<version>0.1.0</version>
</dependency>
Store bytes once
When two users upload the same file, dedup4j recognises the content and stores the bytes once.
Your database, your store
It reuses your existing DataSource and writes bytes to a filesystem directory, S3 or Azure. No separate datastore.
Reference counted
Your application keeps its own asset records; dedup4j owns the physical content and counts who still needs it.
Auto-configured
The starter wires everything against your existing DataSource. It does not open its own connection pool.
Two things dedup4j does not do
Read this before designing around it
It does not generate presigned URLs. dedup4j hands you a
BlobReference and can stream content back to you, but issuing
time-limited direct-to-storage URLs is your application's job. See
Retrieval, retain & release.
It cannot make the database write and the object-store write atomic. Two systems, no shared transaction. dedup4j is explicit about the ordering it chooses and what reconciliation exists for the gap. See Architecture & limitations.
These are the two expectations most likely to be formed and then disappointed, so they are stated up front rather than buried in the reference.
Where to go next
| If you want to | Read |
|---|---|
| Add it to a project | Installation |
| See it work end to end | Quick start |
| Choose local, S3, or Azure | Storage providers |
| Understand reference counting | Retrieval, retain & release |
| Know what it cannot promise | Architecture & limitations |