frerich
An application wishing to store larger amounts of data typically has two options for doing so:
- A new column on some table can be introduced; Postgres features a
byteatype for this purpose. This is easy to implement but suffers from requiring to hold the complete data in memory when reading or writing, something which may not be viable beyond a few dozen megabytes. Efficient streaming or random-access operations are not practical. - A separate cloud storage (e.g. AWS S3) could be used. This permits streaming but requires complicating the tech stack by depending on a new service. Bridging the two systems (e.g. ‘Delete all uploads for a given user ID’) requires Elixir support.
PostgreSQL features a ‘large objects’ facility which enables efficient streaming access to large (up to 4TB) files. This solves these problems
- Unlike values in table columns, large objects can be streamed into/out of the database and permit random access operations.
- Unlike e.g. S3, no new technology is needed. Large objects live side-by-side with the tables referencing them, operations like ‘Delete all uploads for a given user ID’ are just one
SELECTstatement.
The pg_large_objects | Hex package makes it easy to work with large objects.
The high-level API permits importing or exporting data to/from the database in a convenient and memory-efficient manner, e.g.
# Stream data into large object
{:ok, object_id} =
"/tmp/recording.mov"
|> File.stream!()
|> Repo.import_large_object()
A lower-level API makes it easy to work with parts of large objects by exposing common random-access operations, e.g.
alias PgLargeObjects.LargeObject
{:ok, object} = LargeObject.open(object_id)
PLargeObject.seek(object, 1024)
{:ok, sixteen_bytes} = LargeObject.read(object, 16)
See the documentation at PgLargeObjects — PgLargeObjects v0.2.7 for more.
Trending in Announcing
Hi, I would like to tell about my initiative to further maintain and develop Waffle project which is the fork of Arc library.
The progre...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Localize is the next generation localisation library for Elixir. Think of it as ex_cldr version 3.0. The first version will be released ...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
I’ve moved the strategies out of PowAssent and created a multi-provider framework for Elixir. This way the strategies can be used in any ...
New
Aloha gang,
There’s a new class of AI model out from TypeSafe. Jev is their flagship model. You can learn about it here:
...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
Hi everyone :waving_hand:
I wanted to share something I’ve been building — NowBlind, a random chat app designed to help people discover ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
With advancements in AI gathering pace and set to increasingly accelerate, perhaps it’s worth having an annual thread on the topic - feel...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #elixirconf-us
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance











Showing Posts 1 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
frerich
I just released version: PgLargeObjects — PgLargeObjects v0.2.0
This feature features a couple of documentation fixes, but most notably a ready-made implementation of the Phoenix.LiveView.UploadWriter behaviour: PgLargeObjects.UploadWriter. This makes it easy to consume file uploads in LiveView applications by streaming them straight to the database, using constant memory!
First, use the
:writeroption to Phoenix.LiveView.allow_upload/3 to specify the custom writer. Make sure to pass the:repooption in the tuple to indicate which repository the object should be stored in:Next, when consuming upload entries, extract the object ID referencing the upload and store it in order to be able to reference the data from elsewhere: