p3x-redis-ui is a new Redis GUI which can serve as a backend server or as a desktop application.
Some of the features are coming below.
This Redis database every day in the morning European time CET restores some data, so you may do whatever you want to do.
Besides, you could experience the test app to exit for 1 second, because it could auto update itself. It auto updates itself when the code from Git changes.
Third, it is a snapshot, it is possible, that the features are different from GitHub or NPM as the releases are usually monthly or as they happen.
After downloading the
AppImage, make it an executable.
mkdir -p $HOME/opt
mv ~/Downloads/p3x-redis-ui-a.b.c-d-x86_64.AppImage $HOME/opt/
chmod +x $HOME/opt/p3x-redis-ui-a.b.c-d-x86_64.AppImage
Then you can run it
It then actually integrates itself into the menus and it will auto update itself.
(The GitHub versions are always instant, while the ElectronJs Apps releases are delayed.)
Start up with a server or via a browser and NodeJs/NPM
Start up with a server readme
Some description about the config file readme
- On the test server you can test
- Database 0 - below 10k keys
- Database 1 - 10k keys
- It is fast totally. Given, it is not over for 50 keys / page.
- Database 2 - 100k keys
- You will see, that with large sets, it can take up to 15 seconds to load all the keys (dependent on the workstation and memory) and sort (if you enabled in the settings). It is usable, but it is fancy and fast for smaller key sets.
- Database 3 - 1 million keys
- Given the app pre-loads all keys at once, the browser or the electron app for a small workstation could crash
- The latency is quite long, so the app is not so responsive
- The app is certified to work for max 100k keys, although it works with over 900k keys
- The below functions are happening if the key count is above 110k keys
- Key sorting is disabled
- Searching only allows on server side searching
- In the tree, no fancy information is showing - to reduce the stressing on the browser
- Although, this app works with 1 million keys and reduced functions. For such huge key count, it is recommended to use the pure
The sweet spot for the key count is around 10-20k including key sorting with max 100 key / page and still the app is very responsive. If you have a huge key set, make sure to search on the server and it will be very responsive.
Above 10-20k key count as the key large set grows the GUI latency is including as well.
Of course, we could set a limit and the UI would be always responsive, but there was no request of this feature.
- Works with multiple languages
- Works as a backend
- Works as a desktop via Electron
- I took very careful of the error handling (as much I can find errors)
- Starts with no settings without config, or setup your own config
- Able to create, test, save, delete multiple connections or a readonly connections setup, for shared usage
- Able to use the console and interact with Redis
- TAB or SHIFT + TAB completion like bash is enabled
- Cursor UP or DOWN history is enabled
- Online you are able to choose the tree separator, for example :, /, -, space etc... or even empty separator
- It is based on Redis-Commander and phpRedisAdmin
- You can select the database via console or the drop down.
- The database select drop down shows if the checked database is empty or filled, so you can always know which is filled
- Save button to save the db
- Full statistics pages, can be useful
- This is just a New Kind on the Block in the Redis world, so, of course, there are advantages and disadvantages in the other Redis GUIs
- Dark - Dracula / light themes
- Client side mode searching in keys - small key set
- Server side mode searching in keys - large key set
- Search mode
- the search keys starts with a string key
- the search keys includes a string in the key
- From 320px width, it is supposed to be 100% responsive
- There is a key sorting function, which has a penalty, because it sorts with natural compare, which means it is more human display, then just raw characters, but up to 100k the keys is still ok.
- There is a performance penalty for this application, given it uses AngularJS
ng-repeat for the tree component. The best is if your application uses nested keys (something:nested:good), then the tree will be fast, but, for example, Nextcloud uses about 500 keys inline and it can take 5 seconds to generate the tree.
- Another solution is that instead of the : separator for your app, you can use the / separator. Then it will be much more responsive, see the settings tree separator.
- A second solution is to use paging, the default paging is 50 keys
- Maximum keys for this App
- This application is usable up to 100k keys - given it pre-loads all keys and related info at once plus sorting - with natural comparing ...
- In that case, loading all keys into the browser takes about maximum 5-15 seconds
- For big key set to be usable paging should be a maximum 100 keys / page, though for 50 is the sweetest spot
- This application is not recommended with over 100k keys, because it might just crash the NodeJs server. I can understand there are use cases where you need over 100k keys, but this is not that p3x-redis-ui.
- This app including functions like sorting and tree options that are fancy vs large sets ...
This software is more functional than fast ...
The to do readme
The change log readme
The contributors readme
It creates a package that allows you to compose
p3x-redis-ui-material into one:
Server on GitHub
Client on GitHub
By default, only English is created, but given all strings are from a
JS file, it is very quick to spawn another language eg. German, French, Spanish etc ...
English strings, for the web UI
English strings, for the Electron
For a new language:
This solution is not using REST at all, but instead uses Socket.IO , which is weird, but I like it, it is supposed to be more responsive, as there is no big overhead in the HTTP protocol.
P3X Redis UI playground
Corifeus P3X Redis UI pages
AlternativeTo Redis UI
NPM P3X Redis UI